Live data from Hacker News

Remote Code Execution on a Facebook server

blog.scrt.ch

71–80 of 207 posts

Re: Remote Code Execution on a Facebook server

#72

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

And to be fair, the docs are littered with warnings about not using debug mode in production. Debug mode is open for.... debugging. not production.

Re: Remote Code Execution on a Facebook server

#73
post #47

Earlier quoted context omitted.

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 "…

I'm in absolute agreement. Nerd-culture has been on autopilot for decades and needs to find its next level.

Re: Remote Code Execution on a Facebook server

#74

He got $5k for an arbitrary remote execution bug? What a rip-off.

He received $5,000 for remote code execution on a server in a separate VLAN and containing no user data. Barring another vulnerability to commit something like server-side request forgery across the VLAN, that significantly reduces the actual severity of the vulnerability. You wouldn't be able to chain this execution to impact user accounts or other Facebook servers. You also wouldn't be able to exfiltrate sensitive user data. Realistically, what you'd have is a very privileged server for phishing attacks.

The severity of security vulnerabilities should be judged on their context, not on their classification or category.

Re: Remote Code Execution on a Facebook server

#75
post #47

Earlier quoted context omitted.

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 "…

As someone who attends open source conferences, thank you for your efforts to keep talk titles meaningful :)

(My pet peeve being "$thing 2: electric boogaloo", which just seems to be filling up space with nonsense words - at least "for fun and profit" makes gramatical sense...)

Re: Remote Code Execution on a Facebook server

#76

He got $5k for an arbitrary remote execution bug? What a rip-off.

He should have gone to the black market, better yet sat on it. How long did it take Facebook to come forward with its user privacy violations?

You didn't read the article.

"09.08.2018 20:10 CEST : a 5000$ bounty is awarded – the server was in a separate VLAN with no users’ specific data."

Re: Remote Code Execution on a Facebook server

#77
post #28

Wow, a fix in <24 hours, that's pretty impressive.

I mean the fix is toggling a single environmental variable from True to False, on a system that isn't normally accessed by customers, so the risk is really small in rolling out the change.

Hopefully they also changed the compromised key.

Re: Remote Code Execution on a Facebook server

#80
post #55

Earlier quoted context omitted.

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…

Ah, if that's the case, this thread makes more sense. Thanks!
Post reply on HN