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

121–130 of 207 posts

Re: Remote Code Execution on a Facebook server

#121

Post by jrochkind1 »

alrs wrote: post #73
kashyapc wrote: post #66

Earlier quoted context omitted.

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.

Part of nerd culture finding it's next level will be we stop saying "next level".

Re: Remote Code Execution on a Facebook server

#122

Post by ryandrake »

Shish2k wrote: post #75
kashyapc wrote: post #66

Earlier quoted context omitted.

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

Don’t forget “How I learned to stop worrying and love [thing]”.

Just stop with these. They aren’t funny or original.

Re: Remote Code Execution on a Facebook server

#123

Post by jrochkind1 »

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

Re: Remote Code Execution on a Facebook server

#124

Post by whatshisface »

rmetzler wrote: post #102
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…

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.

Re: Remote Code Execution on a Facebook server

#125

Post by alrs »

nikanj wrote: post #118
alrs wrote: post #73

Earlier quoted context omitted.

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

Memes are the next level, it seems

It certainly was in 1994.

https://www.wired.com/1994/10/godwin-if-2/

Re: Remote Code Execution on a Facebook server

#126

Post by smsm42 »

So, summarily we have:

1. Enabling debug mode in production

2. Running publicly-accessible app with publicly-accessible crash screens without any monitoring system noticing it's happening

3. Relying on auto-cleaning in debug facilities to sanitize security information (never works)

4. Using over-powered serialization protocol which allows for code execution for storing user-accessible data

5. Thinking that merely signing content prevents abuse of (4)

Not bad.

Re: Remote Code Execution on a Facebook server

#127

Post by jwilk »

tyleraldrich wrote: post #76
0x8BADF00D wrote: post #71

Earlier quoted context omitted.

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

From the HN guidelines:

Please don't insinuate that someone hasn't read an article.

Re: Remote Code Execution on a Facebook server

#128

Post by mandeepj »

bluntfang wrote: post #88
mandeepj wrote: post #79

> I found a Sentry service hosted on 199.201.65.36 I do not remember on top of my head now but I think there are few scanning software to find all the running apps on a remote machine. If you are aware then please share

https://builtwith.com/

Shoot. It did not strike me. I thought it was good only for web apps and not in-background running processes like Pickle (a binary protocol )

Re: Remote Code Execution on a Facebook server

#129

Post by Polycryptus »

Grollicus wrote: post #120

This is a good example why you need regular pentests in big companies. Everyone (should) know that using pickle is insecure and everyone (should) know that django debug should be False in production. Still, if the numbers get large enough someone will miss something.

The use of Pickle isn't uncommon for session cookies in Python apps, from what I've seen. Pickle isn't really a problem unless you end up unserializing untrusted data... which a sign+encrypt scheme is supposed to ensure doesn't happen. You just can't leak the secret key or you're in trouble.

Though, there's no excuse for leaving Django debug on in production.

Re: Remote Code Execution on a Facebook server

#130

Post by smsm42 »

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 reply on HN