5 ms·

This is why you (looking at frameworks) should never use a format that may contain code to store data, especially when the client has control over that data (ev

This is why you (looking at frameworks) should never use a format that may contain code to store data, especially when the client has control over that data (even if signed). The same vulnerability has occurred in almost every language/framework that does this, including Rails and Java-based ones. Just use something like JSON, which completely avoids code execution vulnerabilities like this. Except of course for the early JavaScript JSON parsers that just used eval for parsing...

rmetzler 8y ago
And "something like JSON" could mean YAML, which had it's own share of RCE bugs. It's still better than these object deserialization bugs one can find in Java or Python Pickle, which seems to be even more permissive.
- whatshisface 8y ago
  Python Pickle RCE is hardly even a bug - because it is meant to deserialize objects (including functions!) for a language that is almost completely dynamic. Indeed, "discovering" that your unpickling is vulnerable to remote code execution is not too far from discovering RCE in a plan to compress data to the Kolmogorov limit by allowing users to send you arbitrary x86 binaries.
someguy101010 8y ago
I agree with the sentiment, and it is very easy to avoid this in Django through the use of either Environment Variables, or importing the relevant setting data with a JSON file. As long as you follow best practices (easier said than done) its easy to mitigate these sort of risks. Also debug mode in production is just lazy.
jrochkind1 8y ago
Even without the pickle-related vulnerability, exposing your secret key that is securing cookies seems pretty bad and likely to lead to other vulnerabilities, although they'd take longer to find. And if the secret key were secure, the pickle use would not be vulnerable. Still, multiple layers of security, yadda yadda, sure. But this is beyond the pickle issue. I'm not sure I'm completely convinced you should not use pickle for browser cookies that are appropriately cryptographically verified. (although fwiw I believe Rails changed it's default cookie serialization to use json instead of the ruby equivalent to pickle which suffered from the same issues).
- bm1362 8y ago
  Isn’t it still an escalation of privileges? You’ve gone from having a proper session of system A (limited damage potentially) into code execution on machine Z.
  - jrochkind1 8y ago
    yup, sounds right.
smsm42 8y ago
PHP has this problem too - never use PHP unserialize() to unserialize hostile (i.e. user-accessible) data. It won't end well for you. I think it's true for any sufficiently powerful serialization format...
- PetahNZ 8y ago
  Had, https://wiki.php.net/rfc/secure_unserialize https://wiki.php.net/rfc/secure_unserialize (but yes you still need to implement a safe unserialize white list)
collinmanderson 8y ago
Yes, Django realized this 7 years ago [0], and JSON has been the default for the past 5 years[1], it's just that facebook was using an old version of Django, and probably not the default. [0] https://groups.google.com/d/msg/django-developers/YwlZ9m9k1bE/P-bJqoatgH8J https://groups.google.com/d/msg/django-developers/YwlZ9m9k1b... [1] https://github.com/django/django/commit/b0ce6fe656873825271bacb55e55474fc346c1c6 https://github.com/django/django/commit/b0ce6fe656873825271b...
- js2 8y ago
  Sentry still requires Django 1.6: https://github.com/getsentry/sentry/blob/ea8fe10d117f5325f9e457f4ca727c82c4d63557/requirements-base.txt#L14 https://github.com/getsentry/sentry/blob/ea8fe10d117f5325f9e...
  - dbrgn 8y ago
    Whoa, really? Django 1.6 has been out of extended support since April 2015, if I read https://www.djangoproject.com/download/ https://www.djangoproject.com/download/ correctly...
    - the_mitsuhiko 8y ago
      We maintain our own patches. We want to upgrade but because the migration framework we use does not support newer versions of Django finding a good upgrade path has been suboptional. It's likely we're going to just make the migration framework compatible with newer Djangos (work is under way).
vhost- 8y ago
I also don't understand why frameworks insist on returning debug data as part of the response. If you are working on something in a development cycle and need debug information, surely you have access to the server that's running in your console. I've always printed debug information there and then send the response. That prevents these kinds of leaks if the server is deployed with debug turned on.
- Myrmornis 8y ago
  1. Pretty formatting of stack traces and other info, including making use of CSS and Javascript. For an extreme example, consider Werkzeug which allows stack frames to be inspected interactively in the tendered stack trace. 2. There are many situations where the person who we want to see the stack trace and debug output does not have access to the console output. E.g. hosting the service internally for a QA team. In general, it is an error often made by people who focus on security to think that security considerations always trump convenience. In fact, it is a trade off like any other.

rmetzler 8y ago

And "something like JSON" could mean YAML, which had it's own share of RCE bugs. It's still better than these object deserialization bugs one can find in Java or Python Pickle, which seems to be even more permissive.

whatshisface 8y ago
Python Pickle RCE is hardly even a bug - because it is meant to deserialize objects (including functions!) for a language that is almost completely dynamic. Indeed, "discovering" that your unpickling is vulnerable to remote code execution is not too far from discovering RCE in a plan to compress data to the Kolmogorov limit by allowing users to send you arbitrary x86 binaries.

someguy101010 8y ago

I agree with the sentiment, and it is very easy to avoid this in Django through the use of either Environment Variables, or importing the relevant setting data with a JSON file. As long as you follow best practices (easier said than done) its easy to mitigate these sort of risks. Also debug mode in production is just lazy.

jrochkind1 8y ago

Even without the pickle-related vulnerability, exposing your secret key that is securing cookies seems pretty bad and likely to lead to other vulnerabilities, although they'd take longer to find. And if the secret key were secure, the pickle use would not be vulnerable. Still, multiple layers of security, yadda yadda, sure. But this is beyond the pickle issue. I'm not sure I'm completely convinced you should not use pickle for browser cookies that are appropriately cryptographically verified. (although fwiw I believe Rails changed it's default cookie serialization to use json instead of the ruby equivalent to pickle which suffered from the same issues).

bm1362 8y ago
Isn’t it still an escalation of privileges? You’ve gone from having a proper session of system A (limited damage potentially) into code execution on machine Z.
- jrochkind1 8y ago
  yup, sounds right.

smsm42 8y ago

PHP has this problem too - never use PHP unserialize() to unserialize hostile (i.e. user-accessible) data. It won't end well for you. I think it's true for any sufficiently powerful serialization format...

PetahNZ 8y ago
Had, https://wiki.php.net/rfc/secure_unserialize https://wiki.php.net/rfc/secure_unserialize (but yes you still need to implement a safe unserialize white list)

collinmanderson 8y ago

Yes, Django realized this 7 years ago [0], and JSON has been the default for the past 5 years[1], it's just that facebook was using an old version of Django, and probably not the default. [0] https://groups.google.com/d/msg/django-developers/YwlZ9m9k1bE/P-bJqoatgH8J https://groups.google.com/d/msg/django-developers/YwlZ9m9k1b... [1] https://github.com/django/django/commit/b0ce6fe656873825271bacb55e55474fc346c1c6 https://github.com/django/django/commit/b0ce6fe656873825271b...

js2 8y ago
Sentry still requires Django 1.6: https://github.com/getsentry/sentry/blob/ea8fe10d117f5325f9e457f4ca727c82c4d63557/requirements-base.txt#L14 https://github.com/getsentry/sentry/blob/ea8fe10d117f5325f9e...
- dbrgn 8y ago
  Whoa, really? Django 1.6 has been out of extended support since April 2015, if I read https://www.djangoproject.com/download/ https://www.djangoproject.com/download/ correctly...
  - the_mitsuhiko 8y ago
    We maintain our own patches. We want to upgrade but because the migration framework we use does not support newer versions of Django finding a good upgrade path has been suboptional. It's likely we're going to just make the migration framework compatible with newer Djangos (work is under way).

vhost- 8y ago

I also don't understand why frameworks insist on returning debug data as part of the response. If you are working on something in a development cycle and need debug information, surely you have access to the server that's running in your console. I've always printed debug information there and then send the response. That prevents these kinds of leaks if the server is deployed with debug turned on.

Myrmornis 8y ago
1. Pretty formatting of stack traces and other info, including making use of CSS and Javascript. For an extreme example, consider Werkzeug which allows stack frames to be inspected interactively in the tendered stack trace. 2. There are many situations where the person who we want to see the stack trace and debug output does not have access to the console output. E.g. hosting the service internally for a QA team. In general, it is an error often made by people who focus on security to think that security considerations always trump convenience. In fact, it is a trade off like any other.