Re: [Django] #14634: Sessions are unnecessarily complex

[Django]

#14634: Sessions are unnecessarily complex
---+
   Reporter:  PaulM| Owner:  PaulM
 Status:  closed   | Milestone:  1.3  
  Component:  django.contrib.sessions  |   Version:  1.2  
 Resolution:  wontfix  |  Keywords:   
   Triage Stage:  Accepted | Has patch:  0
Needs documentation:  0|   Needs tests:  0
Patch needs improvement:  0|  
---+
Changes (by PaulM):

  * status:  new => closed
  * resolution:  => wontfix


Comment:

 I'm closing this as wontfix. In light of the recent security release where
 this extra checking did in fact prevent a more serious problem, I now
 agree that the tradeoff is reasonable.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14634: Sessions are unnecessarily complex

[Django]

#14634: Sessions are unnecessarily complex
--+-
  Reporter:  PaulM| Owner:  PaulM
Status:  new  | Milestone:  1.3  
 Component:  django.contrib.sessions  |   Version:  1.2  
Resolution:   |  Keywords:   
 Stage:  Accepted | Has_patch:  0
Needs_docs:  0|   Needs_tests:  0
Needs_better_patch:  0|  
--+-
Comment (by PaulM):

 This ticket does not intersect with #14579, which should indeed be fixed.

 The proposed fix would allow users to retain granularity with relation to
 the existing checksum behavior. Your proposed situation with an attacker
 who has DB write permissions is not relevant. An attacker who has write
 access to the database may modify user permissions to grant a limited
 account superuser status. We don't hash and checksum those.

 More generally, what makes session data worthy of extra protection within
 a framework that we already trust with other highly sensitive data? Is
 your position that all pickled values in Django must be protected with
 HMAC to prevent potential code execution? It might not be a bad option.

 I will concede that it would be best to retain the check for sessions
 stored on the filesystem. That is not an especially high performance
 option, and it is a likely area for security misconfiguration.

 I will send you a private email with a few more points.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14634: Sessions are unnecessarily complex

[Django]

#14634: Sessions are unnecessarily complex
--+-
  Reporter:  PaulM| Owner:  PaulM
Status:  new  | Milestone:  1.3  
 Component:  django.contrib.sessions  |   Version:  1.2  
Resolution:   |  Keywords:   
 Stage:  Accepted | Has_patch:  0
Needs_docs:  0|   Needs_tests:  0
Needs_better_patch:  0|  
--+-
Comment (by lukeplant):

 Personally I'm in favour of fixing #14579 to enable a cookie backend.

 There is also a pretty good argument for retaining this check even when
 storing the data in a 'trusted' datastore - essentially that not all
 pieces of infrastructure are equally trusted or equally open to attack,
 and layers of security are good.

 Consider a situation where the attacker has write access to the database,
 but not read or write access to the source code of the application. In
 many situations, that will be 'game over' as far as security is concerned,
 but not all. Alternatively, consider the case where the attacker has write
 access to part of the filesystem, or the cache backend, but nothing else,
 and the app is using the filesystem or cache session backend. Now, it is
 relatively easy to create 'pickled' values that will execute arbitrary
 commands when unpickled (not just provide arbitrary values). So, without
 this tamper check, a breach of filesystem/cache/database will escalate
 into the ability to execute arbitrary commands.

 A real life situation where this might occur is a shared hosting
 environment where the '/tmp' directory is used for the filesystem session
 backend — which is the default directory for the filesystem session
 backend. Since this directory is often world-writable (even if the files
 created there are not world readable), an attacker could well use this to
 do arbitrary code injection. A quick check on a server I know suggests
 this might well be a very practical attack since I can see hundreds of
 files in /tmp that appear to be PHP session files.  Although I can't read
 them, I think I can delete them easily, and if they were Django session
 files with no tamper check then I could replace them with some malicious
 data. The owners of the corresponding web apps certainly have some
 security issues - I can delete all of their sessions - but with a tamper
 check in place, it is no worse than that.

 So, I'm pretty strongly in favour of keeping this layer of protection. It
 is a worthwhile check given the escalation of privileges it could prevent
 in some fairly likely situations.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14634: Sessions are unnecessarily complex

[Django]

#14634: Sessions are unnecessarily complex
--+-
  Reporter:  PaulM| Owner:  PaulM
Status:  new  | Milestone:  1.3  
 Component:  django.contrib.sessions  |   Version:  1.2  
Resolution:   |  Keywords:   
 Stage:  Accepted | Has_patch:  0
Needs_docs:  0|   Needs_tests:  0
Needs_better_patch:  0|  
--+-
Changes (by gabrielhurley):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 This seems like a reasonable assessment to me, and I'm +1 on not doing
 unnecessary checks... as for the solution, it sounds alright, though I
 haven't looked deeply into the code there.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.