Remote Code Execution on a Facebook server

Post by tptacek » Sat, Aug 25, 2018, 4:31 AM UTC

sterlind wrote: post #190

tptacek wrote: post #188

Earlier quoted context omitted.

Look, this is Hacker News, I know you can come up with 1,000 different random arguments for why Facebook was wrong and this guy was right. What I can tell you with confidence is that if you did what this researcher did as a contract pentester, you'd get your firm permanently fired from Facebook (or virtually any other major site you might have been testing), and would probably be immediately fired yourself. What he d…

Makes sense; I don't know the pentesting industry too well, nor the norms of bug bounty programs. Certainly his sort of behavior would give me the heebie-jeebies if I ran security at a firm like that. Thinking more on it, I think he was edging black hat and used the rules lawyering as an excuse for pushing past an ethical limit. You've changed my view.

Post by PetahNZ » Sat, Aug 25, 2018, 5:50 AM UTC

smsm42 wrote: post #130

matharmin wrote: post #83

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…

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

Post by bm1362 » Sat, Aug 25, 2018, 7:07 AM UTC

jrochkind1 wrote: post #123

matharmin wrote: post #83

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…

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…

Post by the_mitsuhiko » Sat, Aug 25, 2018, 8:57 AM UTC

dbrgn wrote: post #194

js2 wrote: post #166

Earlier quoted context omitted.

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

Post by the_mitsuhiko » Sat, Aug 25, 2018, 10:26 AM UTC

exikyut wrote: post #33

chatmasta wrote: post #17

Earlier quoted context omitted.

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.

Ah. You're right, I completely got this bit wrong. Thanks. Wait, so that means Sentry kind of has a vulnerability.