Open Stack

On Thu, Oct 3, 2013 at 11:48 PM, Kurt Seifried <kseifried at redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/03/2013 09:39 PM, Paul McMillan wrote:
>> Hi Kurt,
>>
>> The upstream Django team would be extremely happy if you refrained
>> from assigning a CVE for a clearly documented security tradeoff,
>> which is mentioned covered in both the Django and the Horizon docs,
>> as well as in the Openstack Security Guide.
>>
>> The upshot of this entire business is that if you rely soly on
>> client-side cookies, logging out deletes the cookie from a local
>> browser, but does not actually invalidate it until the session
>> expiry timeout. If you don't like this particular technical
>> limitation using client side sessions, you are advised not to use
>> that cookie backend.
>>
>> https://docs.djangoproject.com/en/1.5/topics/http/sessions/#using-cookie-based-sessions
>>
>>
>>
> This does NOT deserve a CVE.
>>
>> Regards, -Paul
>
> Yeah this is usually why i research things a bit before assigning a CVE.
>
> So based on
>
> https://docs.djangoproject.com/en/1.5/topics/http/sessions/#using-cookie-based-sessions
>
> No freshness guarantee
>
> Note also that while the MAC can guarantee the authenticity of the
> data (that it was generated by your site, and not someone else), and
> the integrity of the data (that it is all there and correct), it
> cannot guarantee freshness i.e. that you are being sent back the last
> thing you sent to the client. This means that for some uses of session
> data, the cookie backend might open you up to replay attacks. Unlike
> other session backends which keep a server-side record of each session
> and invalidate it when a user logs out, cookie-based sessions are not
> invalidated when a user logs out. Thus if an attacker steals a user’s
> cookie, he can use that cookie to login as that user even if the user
> logs out. Cookies will only be detected as ‘stale’ if they are older
> than your SESSION_COOKIE_AGE.
>
> I would say this falls into the Python Pickle() group (large red
> banner), a potentially dangerous feature with a large warning. Ergo no
> CVE.
>
> My one comment would be to possibly make the reply warning more
> prominent and also mention protecting the cookie with HTTPS (wireless
> networks in coffee shops/etc.).
What precisely is OpenStack going to do to ensure Django is always in
an approved configuration (or ships in a secure configuration)?

Are there any UI warnings when moving from a secure configuration to a
potentially insecure configuration?

Are the QA folks or Release team aware they need to inspect a setting
and check a box?

(Forgive my ignorance - I'm still learning policy and procedures).

Jeff