New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible exploit of beaker.session #128

Closed
moschlar opened this Issue Jan 24, 2013 · 5 comments

Comments

Projects
None yet
2 participants
@moschlar
Owner

moschlar commented Jan 24, 2013

@danghvu proposes an exploit based on the beaker.sesson library and the Pickle protocol, which is exploitable if the attacker knows the secret key for encrypting the data: https://github.com/danghvu/pwp/blob/master/exploit.py

To be secure against such attacks, we must make sure that the secret key is not retrievable by any means. Relying on the operating system's user privilege handling is one part, but there are other options:

  • Explore how to simply disable beaker.session, since we do not use it anyway
  • Generate new secret keys on each start of the application
@danghvu

This comment has been minimized.

Show comment
Hide comment
@danghvu

danghvu Jan 24, 2013

you are fast... More about it here
http://vudang.com/2013/01/python-web-framework-from-lfr-to-rce/
SAUCE is probably not vulnerable, but remote code execution is already a nature of SAUCE, at least on the server that you compile and run the code, so just make sure it's secured.

danghvu commented Jan 24, 2013

you are fast... More about it here
http://vudang.com/2013/01/python-web-framework-from-lfr-to-rce/
SAUCE is probably not vulnerable, but remote code execution is already a nature of SAUCE, at least on the server that you compile and run the code, so just make sure it's secured.

@moschlar

This comment has been minimized.

Show comment
Hide comment
@moschlar

moschlar Jan 25, 2013

Owner

Okay, I checked it, it seems as if beaker.SessionMiddleware, which is directly used by the TurboGears WSGI stack uses lazy SessionObjects (https://github.com/bbangert/beaker/blob/master/beaker/middleware.py#L137 and https://github.com/bbangert/beaker/blob/master/beaker/session.py#L629) - so if there is no actual access to the session, data from the cookie won't be unpickled at all.

Owner

moschlar commented Jan 25, 2013

Okay, I checked it, it seems as if beaker.SessionMiddleware, which is directly used by the TurboGears WSGI stack uses lazy SessionObjects (https://github.com/bbangert/beaker/blob/master/beaker/middleware.py#L137 and https://github.com/bbangert/beaker/blob/master/beaker/session.py#L629) - so if there is no actual access to the session, data from the cookie won't be unpickled at all.

@danghvu

This comment has been minimized.

Show comment
Hide comment
@danghvu

danghvu Jan 25, 2013

Actually ! SAUCE is vulnerable, your demo site can be owned anytime now since it uses the default setting (same validate-key as in your repo). Check .pgpass ;).
Take a closer look at the source: SessionObjects actually calls CookieSession (https://github.com/bbangert/beaker/blob/master/beaker/session.py#L652) if params.get('type') == 'cookie':. This is exactly your default configuration beaker.session.type=cookie.

danghvu commented Jan 25, 2013

Actually ! SAUCE is vulnerable, your demo site can be owned anytime now since it uses the default setting (same validate-key as in your repo). Check .pgpass ;).
Take a closer look at the source: SessionObjects actually calls CookieSession (https://github.com/bbangert/beaker/blob/master/beaker/session.py#L652) if params.get('type') == 'cookie':. This is exactly your default configuration beaker.session.type=cookie.

@moschlar

This comment has been minimized.

Show comment
Hide comment
Owner

moschlar commented Jan 25, 2013

@moschlar

This comment has been minimized.

Show comment
Hide comment
@moschlar

moschlar Feb 5, 2013

Owner

1c73f33#L0R130 disables the beaker SessionMiddleware as a whole.

Owner

moschlar commented Feb 5, 2013

1c73f33#L0R130 disables the beaker SessionMiddleware as a whole.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment