Opened 8 months ago

Closed 7 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 (8)

comment:1 Changed 8 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 8 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 8 months ago by Simon Charette (previous) (diff)

comment:3 in reply to:  2 Changed 8 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 8 months ago by Simon Charette

Cc: Simon Charette added

comment:5 Changed 8 months ago by Mariusz Felisiak

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

comment:6 Changed 8 months ago by Mark

Owner: changed from nobody to Mark
Status: newassigned

comment:7 Changed 8 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 7 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.

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