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

Cloudflare Reverse Proxies Are Dumping Uninitialized Memory

bugs.chromium.org

Post reply on HN
Print view View original

701–710 of 1001 posts

Re: Cloudflare Reverse Proxies Are Dumping Uninitialized Memory

#701

Post by ars »

oldsj wrote: post #549
Kalium wrote: post #448

Earlier quoted context omitted.

They're human too. Look at the response times!

Yea but... seems like a quick run of valgrind would have caught this

Not necessarily.

If they just keep reusing a buffer and forget to clear it in between requests there is nothing automated that would find it.

Bounds checking languages would not help either - they would only work if they delete and reallocate the buffer on each request, since that's slow it's unlikely anyone would do that.

They probably wouldn't even clear the buffer, instead they rely on keeping track of the length of data in it, so any errors in there would be a problem.

Re: Cloudflare Reverse Proxies Are Dumping Uninitialized Memory

#702

Post by a3_nm »

jkells wrote: post #44

My first thought was relief, thank god I'm not using Cloudflare. Where would you even start to address this? Everything you've been serving is potentially compromised, API keys, sessions, personal information, user passwords, the works. You've got no idea what has been leaked. Should you reset all your user passwords, cycle all or your keys, notify all your customers that there data may have been stolen? My second th…

I won't take the initiative of changing passwords, and I will only be doing it for services that ask me to do it.

In my opinion, if my accounts get compromised because the provider uses Cloudflare and leaks my data all over, it's their fault, not mine... It's not my job to guess which services are using Cloudflare, which ones were affected... and further, if my account gets compromised, others presumably will.

(PS: Of course you may need to change passwords if you reuse passwords from one service to the other, but obviously you shouldn't be doing that in the first place.)

Re: Cloudflare Reverse Proxies Are Dumping Uninitialized Memory

#703

Post by saiya-jin »

hoorayimhelping wrote: post #85
_wmd wrote: post #11

Step 1) MITM the entire Internet, undermining its SSL infrastructure, build a business around it Step 2) leak cleartext from said MITM'd connections to the entire Internet I recently noted that in some ways Cloudflare are probably the only entity to have ever managed to cause more damage to popular cryptography since the 2008 Debian OpenSSL bug (thanks to their "flexible" ""SSL"" """feature"""), but now I'm certain o…

> edit: why the revulsion I'd guess it's because of the crude and reductive way you describe the service cloudflare provides. I don't know what type of programming you do, but many small services don't have the infrastructure to mitigate the kind of attacks cloudflare deals with and they wouldn't be around without services like this. I don't like the internet becoming centralized into a few small places that mitigate…

from wikipedia [1]: - Cloudflare was ranked in the 7th rank among the top 50 Bad Hosts by HostExploit.[41] The service has been used by Rescator, a website that sells payment card data

- Two of ISIS' top three online chat forums are guarded by Cloudflare

- An October 2015 report found that Cloudflare provisioned 40% of SSL certificates used by phishing sites with deceptive domain names resembling those of banks and payment processors.

and so on... WTF is wrong with those guys? money-first approach?

[1] https://en.wikipedia.org/wiki/Cloudflare#Criticism_and_contr...

Re: Cloudflare Reverse Proxies Are Dumping Uninitialized Memory

#704

Post by ars »

AYBABTME wrote: post #317

This comes around to me as something that just shouldn't have happened. CloudFlare are pretty big on Go, as far as I can tell (and I guess Lua for scripting nginx). Why was this parsing package written in a non memory-safe language? Parsing is one of those "obvious" things easy to mess up; the likelihood of a custom, hand written parser being buggy is pretty high. If it's somehow understood that your library is likel…

This could easily happen in Go as well. All that would be needed is to reuse the buffer in between requests, and rely on the buffer length instead of clearing it.

To make it safer you would need to deallocate and reallocate the buffer for each request, but that might be slow. Doing that would fix it for Go, or for C, it would be the same either way.

So I'm not convinced that using Go would have helped here.

Re: Cloudflare Reverse Proxies Are Dumping Uninitialized Memory

#706

Post by anc84 »

_wmd wrote: post #91
tptacek wrote: post #79

Earlier quoted context omitted.

In case you're wondering how this could be worse than Heartbleed: Yes, apparently the allocation patterns inside Cloudflare mean TLS keys aren't exposed to this vulnerability. But Heartbleed happened at the TLS layer. To get secrets from Heartbleed, you had to make a particular TLS request that nobody normally makes. Cloudbleed is a bug in Cloudflare's HTML parser, and the secrets it discloses are mixed in with, appa…

It shouldn't be too difficult to feed an instrumented copy of the parser some fraction of their cached pages (after all, that's what they're for.. right?) and calculate a percentage of how many triggered e.g. valgrind, or just some magic string tacked on the end of the input appearing in the output or similar I prefer CloudScare to Cloudbleed :)

Buttflare.

Re: Cloudflare Reverse Proxies Are Dumping Uninitialized Memory

#707

Post by adrianN »

a3_nm wrote: post #702
jkells wrote: post #44

My first thought was relief, thank god I'm not using Cloudflare. Where would you even start to address this? Everything you've been serving is potentially compromised, API keys, sessions, personal information, user passwords, the works. You've got no idea what has been leaked. Should you reset all your user passwords, cycle all or your keys, notify all your customers that there data may have been stolen? My second th…

I won't take the initiative of changing passwords, and I will only be doing it for services that ask me to do it. In my opinion, if my accounts get compromised because the provider uses Cloudflare and leaks my data all over, it's their fault, not mine... It's not my job to guess which services are using Cloudflare, which ones were affected... and further, if my account gets compromised, others presumably will. (PS: O…

The damage is still yours even if its not your fault

Re: Cloudflare Reverse Proxies Are Dumping Uninitialized Memory

#709

Post by mcintyre1994 »

tinco wrote: post #696
chimeracoder wrote: post #619

Earlier quoted context omitted.

> If anyone here is HIPAA-regulated or you have a customer who is Cloudflare certainly does; I founded a health tech company, and Cloudflare was the recommended go-to for health tech startups who needed a CDN while serving PHI. And this is definitely a reportable breach. Technically any breach is supposed to be reported to HHS, but in reality, a lot of covered entities (e.g. insurers) fail to report smaller breaches…

Well HIPAA wouldnt allow your https traffic flow unencrypted through a shared proxy right? This means cloudflare couldnt offer that feature, so they probably didn't? Just think about the HIPAA document describing a single endpoint of dozens of sensitive datastreams, decrypting and then encrypting them all on the same machine, a machine that does some random HTML parsing for snippet caching on the side. I don't see th…

From their blog post: https://blog.cloudflare.com/incident-report-on-memory-leak-c...

"Because Cloudflare operates a large, shared infrastructure an HTTP request to a Cloudflare web site that was vulnerable to this problem could reveal information about an unrelated other Cloudflare site."

You don't need to be using this feature, or to be sending malformed HTML yourself - just to be in memory for this Cloudflare process.

Re: Cloudflare Reverse Proxies Are Dumping Uninitialized Memory

#710

Post by jononor »

Blackthorn wrote: post #527

This is probably gonna get buried at this point, but one thing I'm surprised about is this seems like yet another parser bug. Why are we still using hand-written parsers? Even if you're Very Smart, you'll probably get it wrong. We have parser generators for a lot of things. Even for mostly unparseable garbage like wild-type HTML we have pretty good libraries for handling it. Fresh hand-written parsers are just bombs…

I would also expect that regularly performed fuzz testing would be able to catch such a bug? Especially if ran in combination with dynamic memory analysis like Valgrind. So were they not doing this?
Post reply on HN