Open Stack

-----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.).


> On Fri, Oct 4, 2013 at 4:09 AM, Kurt Seifried
> <kseifried at redhat.com> wrote: On 10/03/2013 08:22 PM, Jeffrey
> Walton wrote:
>>>> On Thu, Oct 3, 2013 at 6:30 PM, Jeffrey Walton
>>>> <noloader at gmail.com> wrote:
>>>>> Here's some more reading on the subject. It was recently
>>>>> updated, and effectively states django is susceptible to
>>>>> session management attacks under some configurations. 
>>>>> https://docs.djangoproject.com/en/1.4/topics/http/sessions/#using-cookie-based-sessions.
>>>>
>>>>>
>
>>>>> 
Its now being tracked: VU#160862 (thanks Kurt).
> 
> Just to be clear I didn't do anything yet. That's a US-CERT 
> Vulnerability Note number, nothing to do with CVE. Did you contact
> the Django people about this issue to report it upstream yet?
> Adding security at djangoproject.com in case they haven't seen it
> yet.
> 
> This is regarding
> 
> http://maverickblogging.com/security-vulnerability-with-django-cookie-based-sessions/
>
>  I'm going to assign a CVE if I can somewhat confirm a CVE hasn't
> been requested yet.
> 
> 

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJSTjqaAAoJEBYNRVNeJnmTz+MP/jzKxzkRr3i9G9tMSi9HO8fn
9z3gx1rDQ6YcsucSEma4klqFBa1hV9RE/LQqJBVup7g5wBQYFq6e+V2JHOnz0ohM
hTn7GSRpusQxQaouEZJyy0lK1hrTBIEARaLbbNsn4I2yyb6Kq/xnbUXwmCpBb8Nf
ZhIbamdI/nAdWINRgzypQiGSK6eMjX+VbamRvealgRdk1dm5mlJxDyBkXFqAsXEf
JHrEnsZ7KjNzwjJPRdcif9kS93BegCv/hBnueP0SWipIuRSfizAgTyLn/KlqSVLW
2ByL1OgrvMZkpPTRpfAOXrmYcBdjrJd8lf5ENdookxTf6yK5IZvRy33TP07mKZAv
wDrKfQBllxmTX1ZYAdpKg1yfGlkESU1mSE2TzyUJMsa0fBW0sB8wGpjmL3boZE77
/90MmGfxBzc0DBEuMRMCQ7TaME7IsHbZayG3davN2T+h3N8EHiIDlus3PFai2+rJ
fNOP5aGtTUcBMfJObI3T6m8D9C6tgaB6wuBsgGP/p9X1/+htQjVJtVQWopdBLQ7a
/hTczkeIGGiputzRxZS/EX+OhFFuJ7voMOpy/Mhi08patdHe5ZRy83ltMFGO30mD
wMhYmqOmzWZCsLYCCbEtPSCr0vjHpYBUhAF4Y4MTAv+Vhw8miugBCsWJ4MS+7Ud/
tEq6pZfsZ3dw1Zs/I1vh
=GCVi
-----END PGP SIGNATURE-----