4 ms·

So, this was simply taking advantage of a crash-prone webapp running on a debug-enabled Django instance using Pickle session serialization, and more specificall

So, this was simply taking advantage of a crash-prone webapp running on a debug-enabled Django instance using Pickle session serialization, and more specifically this was only possible because _Django didn't redact the stored secret key used to sign serialized inputs out of the crashdump information!_ Did the author tell Django about this yet, or is this a (possibly unintentional) 0-day? Besides the above interestingness, the morals of this story I get are - Stay persistent and leave your scanners running; you never know what new things will turn up. - Crashdumps _are_ interesting - Yay, $5,000! - Middleware and frameworks will always clash in useful and interesting ways?

ch0wn 8y ago
If I remember correctly, Django only shows these information if left in debug mode. Needless to say, this should never be used in production.
acidburnNSA 8y ago
Django is pretty serious about warning you of the risks of this [1]. I think in this case the key was in some third party options variable so the bug is there. The sentry thing sounds like an internal bug to Facebook rather than a django issue. [1] https://docs.djangoproject.com/en/2.1/topics/http/sessions/#using-cookie-based-sessions https://docs.djangoproject.com/en/2.1/topics/http/sessions/#...
chatmasta 8y ago
Maybe I misunderstood the article, but I thought it said that Django does strip this information, and the Sentry app went out of its way to store the secret key in the SENTRY_OPTIONS payload. This custom, non-Django code effectively circumvents Django’s protections, making the bug the responsibility of Sentry, not Django.
- exikyut 8y ago
  Ah. You're right, I completely got this bit wrong. Thanks. Wait, so that means Sentry kind of has a vulnerability.
  - deleted 8y ago
    [deleted]
  - the_mitsuhiko 8y ago
    Sentry does secure `DEBUG` mode. It's for development only and must not be set by customers. That said, we will try to make it less easy to set by accident: https://github.com/getsentry/sentry/pull/9516 https://github.com/getsentry/sentry/pull/9516
C14L 8y ago
It was a Sentry specific "secret-key" that was overriding Django's.

ch0wn 8y ago

If I remember correctly, Django only shows these information if left in debug mode. Needless to say, this should never be used in production.

acidburnNSA 8y ago

Django is pretty serious about warning you of the risks of this [1]. I think in this case the key was in some third party options variable so the bug is there. The sentry thing sounds like an internal bug to Facebook rather than a django issue. [1] https://docs.djangoproject.com/en/2.1/topics/http/sessions/#using-cookie-based-sessions https://docs.djangoproject.com/en/2.1/topics/http/sessions/#...

chatmasta 8y ago

Maybe I misunderstood the article, but I thought it said that Django does strip this information, and the Sentry app went out of its way to store the secret key in the SENTRY_OPTIONS payload. This custom, non-Django code effectively circumvents Django’s protections, making the bug the responsibility of Sentry, not Django.

exikyut 8y ago
Ah. You're right, I completely got this bit wrong. Thanks. Wait, so that means Sentry kind of has a vulnerability.
- deleted 8y ago
  [deleted]
- the_mitsuhiko 8y ago
  Sentry does secure `DEBUG` mode. It's for development only and must not be set by customers. That said, we will try to make it less easy to set by accident: https://github.com/getsentry/sentry/pull/9516 https://github.com/getsentry/sentry/pull/9516

C14L 8y ago

It was a Sentry specific "secret-key" that was overriding Django's.