Opened 20 months ago

Closed 20 months ago

Last modified 10 months ago

#31412 closed Bug (wontfix)

Database timing attack against sessions.

Reported by: Brian May Owned by:
Component: contrib.sessions Version: 3.0
Severity: Normal Keywords:
Cc: Simon Charette, Florian Apolloner, Paul McMillan Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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?

Change History (10)

comment:1 Changed 20 months ago 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.

comment:2 Changed 20 months ago by Simon Charette

Looking at Rack patch I think this might have a bit of overlap with #21076 (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.

Last edited 20 months ago by Simon Charette (previous) (diff)

comment:3 in reply to:  2 Changed 20 months ago by Brian May

Replying to Simon Charette:

Looking at Rack patch I think this might have a bit of overlap with #21076 (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).

comment:4 Changed 20 months ago by Simon Charette

Cc: Simon Charette added

comment:5 Changed 20 months ago by Mariusz Felisiak

Cc: Florian Apolloner Paul McMillan added
Summary: database timing attack against sessionsDatabase timing attack against sessions.
Last edited 20 months ago by Mariusz Felisiak (previous) (diff)

comment:6 Changed 20 months ago by Mark

Owner: changed from nobody to Mark
Status: newassigned

comment:7 Changed 20 months ago by Mark

Owner: Mark deleted
Status: assignednew

I deassigned myself because I noticed this issue wasn't accepted yet.

I am picking up #21076 and looking into updating and improving PR#8736

comment:8 Changed 20 months ago by Carlton Gibson

Resolution: wontfix
Status: newclosed

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.

comment:9 Changed 10 months ago by Alexey Shamrin

Carlton, could you please share Django Security Team reasoning about the impractically of session timing attack?

This page shows up if you google for general session storage implementation advice (not specific to Django). It would be nice to learn the details, if you can share them.

Last edited 10 months ago by Alexey Shamrin (previous) (diff)

comment:10 Changed 10 months ago 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 security@… as per the Reporting security issues guidance is appreciated.

Note: See TracTickets for help on using tickets.
Back to Top