beaker.session vulnerability

86 views
Skip to first unread message

Moritz Schlarb

unread,
Jan 25, 2013, 5:48:26 PM1/25/13
to turbo...@googlegroups.com
Hi there,

beaker.session is (like most session frameworks) vulnerable to a
"malicious pickle" attack (if the attacker knows the secret key) when
cookies are used (which can lead to remote code execution).
Now, of course, the secret key is - as its name says - meant to be kept
secret and to be changed for every deployment, and the vulnerabilities
in the pickle protocol are also mentioned in the Python docs.
So, "normal" applications should be safe - as long as there is no
possibility for arbitrary file access.
Though, brute-force decrypting the cookie, looking for something that
looks like pickle'd data could be possible.

But, as an easy solution is to just use beaker.session.type = file
instead of cookie, I think it could be worth either discussing changing
the default or at least mentioning this explicitly in a red box in the
documentation. ;)
- Especially since it also applies to apps that do not actively use
tg.session - since the session gets depickled anyways (and it such
cases, a developer might think that he doesn't need to care about the
secret key at all!).

The vulnerabilities are described here:
http://vudang.com/2013/01/python-web-framework-from-lfr-to-rce/ and a
PoC for an exploit, that can be used is available here:
https://github.com/danghvu/pwp

Regards,
Moritz

--
Moritz Schlarb

Alessandro Molina

unread,
Jan 26, 2013, 5:21:37 AM1/26/13
to TurboGears .
beaker.session.type = file was the default a few releases ago for that same reason.
It has been changed due to people complaining that they were finishing file system inodes due to beaker sessions as they didn't provide a script to clean up sessions.
The solution applied has been to change the default to cookie and let the developer choose his own way to manage sessions on the server.

We can probably add a warning to both cookie and file sessions making the user aware of the limits of both, but I would keep the default on cookie as it seems to satisfy more users as a default.



--
Moritz Schlarb

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



Alessandro Molina

unread,
Jan 26, 2013, 6:00:25 AM1/26/13
to TurboGears .
Also another option can probably be to specify a session encrypt_key for added security in quickstart, in that case the session would not only be validated against the secret key but would also be encrypted with AES. This has the side effect of adding a dependency to quickstarted projects to provide encryption anyway.

Moritz Schlarb

unread,
Jan 26, 2013, 7:50:50 AM1/26/13
to turbo...@googlegroups.com
I tried making it more clear in the documentation: https://github.com/TurboGears/tg2docs/pull/19

Alessandro Molina

unread,
Jan 26, 2013, 11:02:32 AM1/26/13
to TurboGears .
Thanks!
I'll try to merge it as soon as possible.

For people that feel the need to make themselves totally safe from pickle based remote execution, it is also possible to monkeypatch beaker from the app_cfg.py so that it uses json.

import beaker.util, json
beaker.util.pickle = json

As json and pickle share the dumps/loads methods and float/int/str types are supported on both storing and recovering the session will work using json.

Moritz Schlarb

unread,
Jan 26, 2013, 11:24:32 AM1/26/13
to turbo...@googlegroups.com
Woah!
That monkeypatch is quite awesome! :D

And as another variant, for those that don't even use the session, they can simply disable the Middleware as described here:

Thanks for merging, Alessandro.
Reply all
Reply to author
Forward
0 new messages