Comment by user5994461
8 years ago
> The greatest period of impact was from February 13 and February 18 with around 1 in every 3,300,000 HTTP requests through Cloudflare potentially resulting in memory leakage (that’s about 0.00003% of requests).
1) From the metrics I recalled when I interviewed there, and assuming the given probability is correct, that means a potential of 100k-200k paged with private data leaked every day.
2) What's the probably that a page is served to a cache engine? Not a clue. Let's assume 1/1000.
3) That puts a bound around a hundred leaked pages saved per day into caches.
4) Do the cache only provide the latest version of a page? I think most do but not all. Let's ignore that aspect.
5) What's the probably that a page contains private user information like auth tokens? Maybe 1/10?
6) So, that's 10 pages saved per day into the internet search caches.
7) That's on par with their announcement: "With the help of Google, Yahoo, Bing and others, we found 770 unique URIs that had been cached and which contained leaked memory. Those 770 unique URIs covered 161 unique domains." Well, not that we know for how long this was running.
8) Now, I don't want to downplay the issue, but leaking an dozen tokens per day is not that much of a disaster. Sure it's bad, but it's not remotely close to the leak of the millennia and it's certainly not internet scale leak.
9) For the record, CloudFlare serves over one BILLION human beings. Given the tone and the drama I expected way more data from this leak. This is a huge disappointment.
Happy Ending: You were probably not affected.
This assumes that the Bad Guys hadn't noticed the bug before Tavis, and hadn't started intensively mining Cloudflare for data.
Intensive mining indeed, if it's true that it requires 3.3M requests to get a page leak.
With a fixed 100Mbps connection and assuming 2kB per HTTP request-response, you can hope to get one leak every 11 minutes and 6.6GB of traffic, which is a constant 5k requests/s.
Maybe if Google reassigns all its SHAterred ressources to doing that...
... and then I realize that we were talking about cloudflare and my mining bot a capcha.
---
edit: correction. The bug was affecting only some pages with some content filtering options enabled, and was more prominent under some specific circumstances.
Hence why it only happens 1/3.3M in average. An attacker could allegedly leak data much more reliably if he was able to identify the patterns that are more likely to trigger leaks.
Couldn't an attacker construct a page that triggers the memory leak and just keep accessing that page to get different pieces of memory?
1 reply →
That's what was observed on the Cloudflare end. Without the multiplicand of how many pages Cloudflare served in a given amount of time, you can't determine the impact. Assuming that affected sites were affected en masse, a targeted attack from a connection would be minuscule compared to the pages Cloudflare serves.
Cloudflare is serving up more than 100Mbps; the attacker only has to zero in on what's fruitful, which yields something far higher than the 1 per 3.3M Cloudflare sees serving millions of innocuous requests.
2 replies →
Botnets
I hope something like intense mining would've caused a detectable spike in turn alerting CF sooner. Looks like it didn't...
Probably not. Cloudflare is designed to automatically swallow large increases in traffic.
I think your estimates fell apart at step 2, 1/1000 pages being cached. HTTP is aggressively cached, on many different layers. I'd put it closer to 1/10.
I meant cached by a public service like Google Cache Bing Archive.org that expose the pages.
A browser cache might be 1/10 but that's not open.
There's a lot of stuff in between those two extremes. As someone that operates an HTTP accelerator and caching server.