Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Remote Code Execution on a Facebook server

blog.scrt.ch

Post reply on HN
Print view View original

61–70 of 207 posts

Re: Remote Code Execution on a Facebook server

#61

Post by kawsper »

Someone1234 wrote: post #29
Areading314 wrote: post #7

This is a great concrete example why you should never run debug mode on a public server. Django can only do so much for redacting private info. This is also a great example of how insecure pickle is!

I know this is going to get some jeering, but that's one nice thing about .Net's machine.config , you designate the machine itself as a non-development environment and tracing, debug output, and so on are disabled for all .Net/ASP.Net applications. That might not work for all edge cases, but broadly there's a lot of machines which are only for non-development/production code, and a system-wide setting makes you a lot…

Funnily enough, it is mostly .NET applications running in production that I see stack-traces from these days.

Re: Remote Code Execution on a Facebook server

#62

Post by [deleted] »

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.

[deleted]

Re: Remote Code Execution on a Facebook server

#64

Post by phinnaeus »

gandreani wrote: post #44
Someone1234 wrote: post #29

Earlier quoted context omitted.

I know this is going to get some jeering, but that's one nice thing about .Net's machine.config , you designate the machine itself as a non-development environment and tracing, debug output, and so on are disabled for all .Net/ASP.Net applications. That might not work for all edge cases, but broadly there's a lot of machines which are only for non-development/production code, and a system-wide setting makes you a lot…

Just a thought. This might actually be trivial to implement in a unix environment from the administration side of things. I'm not 100% sure but all child processes inherit the env vars from the parent correct? So setting `environment=production` high up in the process tree should make it available to all processes. There's still chances of this getting overridden down the line and all apps have to conform to one styl…

Plenty of production apps in my line of work are executed with `env -i` for consistency.

Re: Remote Code Execution on a Facebook server

#65

Post by beefhash »

> Quoting the Sentry documentation, system.secret-key is “a secret key used for session signing. If this becomes compromised it’s important to regenerate it as otherwise its much easier to hijack user sessions.“; wow, it looks like it’s a sort of Django SECRET-KEY override!

One wonders why that is even there. Was Django's own session code not good enough?

Re: Remote Code Execution on a Facebook server

#66

Post by kashyapc »

alrs wrote: post #47
konraditurbe wrote: post #13

Earlier quoted context omitted.

Also the title. Clear and concise without being click-bait (such as Facebook RCE for fun and profit, all your Facebook belong to us, etc...)

Those kinds of titles are really tired, but clickbait is unfair. "X For Fun and Profit" can be found in g-files back to the late '80s, a time well before clicking. http://www.textfiles.com/phreak/

The point is, "for fun and profit" is such an overused and utterly boring cliché. Meaningful titles are pleasant to read and shows that the writer has put some effort to bring clarity into what they're trying to convey. (As someone who sits on a major open source conference talk panel, I cringe when I see one of these clichés slapped into the title without much thought. I politely suggest to rephrase to convey more "signal" in the title.)

Re: Remote Code Execution on a Facebook server

#67

Post by [deleted] »

beefhash wrote: post #65

> Quoting the Sentry documentation, system.secret-key is “a secret key used for session signing. If this becomes compromised it’s important to regenerate it as otherwise its much easier to hijack user sessions.“; wow, it looks like it’s a sort of Django SECRET-KEY override! One wonders why that is even there. Was Django's own session code not good enough?

[deleted]

Re: Remote Code Execution on a Facebook server

#68

Post by hyperpape »

tptacek wrote: post #55
srcmap wrote: post #23

Other than fixing the Django source code , is there any OS level mitigation techniques that can detect and prevent such security vulnerabilities? I am thinking something like selinux, docker or chroot - a bit like internal firewall for Django (or any other webapp). Any suggestions on the links to latest best practices?

Of course. You can lock the process down so that it can't make unexpected system calls. If you deploy in a modern container environment, you can also use container networking to drastically limit what the application environment can talk to on the network. Though it's a less potent mitigation than seccomp and container isolation (and one you get for free once you deploy in a container), you can also limit filesystem…

It seems like several people are discussing whether you can use the OS to prevent the sentry instance from disclosing its own data. You're talking about using the OS to prevent pivoting from that sentry instance to compromise something else.

That said, I'd think it's pretty obvious that you can only address the second part, so it's what's interesting. If your application speaks HTTP, then the OS can't do that much to keep it from doing stupid things over HTTP.

Re: Remote Code Execution on a Facebook server

#70

Post by 5h »

ssebastianj wrote: post #10
Areading314 wrote: post #7

This is a great concrete example why you should never run debug mode on a public server. Django can only do so much for redacting private info. This is also a great example of how insecure pickle is!

Luckily, Django provides checks to avoid this kind of leakage before hitting production with https://docs.djangoproject.com/en/2.1/howto/deployment/check...

They were running django 1.6 ....
Post reply on HN