[Django] #31412: database timing attack against sessions
Django
--------------------------------------------+------------------------
Reporter: Brian May | Owner: nobody
Type: Bug | Status: new
Component: contrib.sessions | Version: 3.0
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
--------------------------------------------+------------------------
CVE-2019-16782 was assigned to Ruby Rack. Basically, an attacker, can
conduct a timing attack by sending specially crafted session ids and
timing how long it takes for the database to lookup the session. From this
the attacker can guess valid session ids.
To me it looks like Django, by default, stores sessions on the database
(using django.contrib.sessions.backends.db) in a very similar manner. Does
this also mean it is vulnerable to the same timing attack?
--
Ticket URL: <https://code.djangoproject.com/ticket/31412>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Brian May | Owner: nobody
Type: Bug | Status: new
Component: contrib.sessions | Version: 3.0
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Brian May):
The security issue referenced here is already public, I don't see any
issues with making this bug report public also. Apologies if I got this
wrong.
--
Ticket URL: <https://code.djangoproject.com/ticket/31412#comment:1>
Django
Reporter: Brian May | Owner: nobody
Type: Bug | Status: new
Component: contrib.sessions | Version: 3.0
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Simon Charette):
Looking at
[https://github.com/rack/rack/commit/7fecaee81f59926b6e1913511c90650e76673b38
Rack patch] I think this might have a bit of overlap with #21076
([https://github.com/django/django/pull/8736 PR]). If session ID were
hashed it wouldn't be possible to use timing attacks on the btree-index to
statistically walk your way to a valid session ID.
--
Ticket URL: <https://code.djangoproject.com/ticket/31412#comment:2>
Django
Reporter: Brian May | Owner: nobody
Type: Bug | Status: new
Component: contrib.sessions | Version: 3.0
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Brian May):
Replying to [comment:2 Simon Charette]:
> Looking at
[https://github.com/rack/rack/commit/7fecaee81f59926b6e1913511c90650e76673b38
Rack patch] I think this might have a bit of overlap with #21076
([https://github.com/django/django/pull/8736 PR]). If session ID were
hashed it wouldn't be possible to use timing attacks on the btree-index to
statistically walk your way to a valid session ID. It might be time to
revive that old PR.
Agreed.
The Rack solution become complicated because (a) they wanted to preserve
existing sessions and (b) for reasons I don't understand they decided to
split the session id into a "public" session id and a "private" session id
where the names "public" (meaning non-hashed id) and "private" (meaning
hashed id) don't mean what you might expect (they both need to remain
secret).
--
Ticket URL: <https://code.djangoproject.com/ticket/31412#comment:3>
Django
Reporter: Brian May | Owner: nobody
Type: Bug | Status: new
Component: contrib.sessions | Version: 3.0
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Simon Charette):
* cc: Simon Charette (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/31412#comment:4>
Django
----------------------------------+--------------------------------------
Reporter: Brian May | Owner: nobody
Type: Bug | Status: new
Component: contrib.sessions | Version: 3.0
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by felixxm):
* cc: Florian Apolloner, Paul McMillan (added)
Comment:
We discussed this
--
Ticket URL: <https://code.djangoproject.com/ticket/31412#comment:5>
Django
----------------------------------+--------------------------------------
Type: Bug | Status: assigned
Component: contrib.sessions | Version: 3.0
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mark):
* owner: nobody => Mark
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/31412#comment:6>
Django
----------------------------------+--------------------------------------
Type: Bug | Status: new
Component: contrib.sessions | Version: 3.0
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mark):
* owner: Mark => (none)
* status: assigned => new
Comment:
I deassigned myself because I noticed this issue wasn't accepted yet.
I ''am'' picking up #21076 and looking into updating and improving
[https://github.com/django/django/pull/8736 PR#8736]
--
Ticket URL: <https://code.djangoproject.com/ticket/31412#comment:7>
Django
----------------------------------+--------------------------------------
Reporter: Brian May | Owner: (none)
Component: contrib.sessions | Version: 3.0
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* status: new => closed
* resolution: => wontfix
Comment:
Thank you for the report.
After consideration, the Django Security Team conclude that this is not a
practical attack vector.
Work on the related hardenings, such as the referenced tickets should
continue.
--
Ticket URL: <https://code.djangoproject.com/ticket/31412#comment:8>
Django
----------------------------------+--------------------------------------
Reporter: Brian May | Owner: (none)
Type: Bug | Status: closed
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by shamrin):
Carlton, could you please share Django Security Team reasoning about the
impractically of session timing attack?
This page shows up if you search for general session storage
implementation advice (not specific to Django). It would be nice to learn
the details, if you can share them.
--
Ticket URL: <https://code.djangoproject.com/ticket/31412#comment:9>
Django
----------------------------------+--------------------------------------
Reporter: Brian May | Owner: (none)
Type: Bug | Status: closed
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Carlton Gibson):
Alexey, what was missing was a demonstration of how this might be
exploited. Yes, work on the related tickets but this wasn't something we
need to pick up as a security issue.
If that is not correct, a proof-of-concept sent privately to
secu...@djangoproject.com as per the
[https://docs.djangoproject.com/en/dev/internals/security/ Reporting
security issues guidance] is appreciated.
--
Ticket URL: <https://code.djangoproject.com/ticket/31412#comment:10>