Hacker News Reader

Comment by matharmin | Hacker News Reader

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...

View on HN

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/YwlZ9m9k1b...

[1] https://github.com/django/django/commit/b0ce6fe656873825271b...

Sentry still requires Django 1.6:

https://github.com/getsentry/sentry/blob/ea8fe10d117f5325f9e...

Whoa, really? Django 1.6 has been out of extended support since April 2015, if I read https://www.djangoproject.com/download/ correctly...

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).

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).

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.

yup, sounds right.

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...

Had, https://wiki.php.net/rfc/secure_unserialize

(but yes you still need to implement a safe unserialize white list)

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.

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.

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.

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.

Reply on news.ycombinator.com