301–310 of 1001 posts
Earlier quoted context omitted.
Good. They're trying to clean up all the private data leaked everywhere. I tempted to say "why couldn't they figure out this google dork themselves" but they've probably been slammed for the past 7 days cleaning up a bunch of stuff anyway.
You have no idea.
Earlier quoted context omitted.
No, nothing is fixed. The leak has been plugged, but the water damage (and partly the water itself) is still there.
Weird. I read the Cloudflare blog entry ( " rel="nofollow">https://blog.cloudflare.com/incident-report-on-memory-leak-c... ) at the bottom of the linked Chromium bug tracker page and they make it sound like it's fixed (the implication being that now would be the time to change all my passwords…)
...but since this bug has been out in the wild since perhaps 2016-09-22, now is indeed, the time to go and reset your active sessions and change all your passwords.
Earlier quoted context omitted.
Good. They're trying to clean up all the private data leaked everywhere. I tempted to say "why couldn't they figure out this google dork themselves" but they've probably been slammed for the past 7 days cleaning up a bunch of stuff anyway.
You have no idea.
Oh, my god. Read the whole event log. If you were behind Cloudflare and it was proxying sensitive data (the contents of HTTP POSTs, &c), they've potentially been spraying it into caches all across the Internet; it was so bad that Tavis found it by accident just looking through Google search results. The crazy thing here is that the Project Zero people were joking last night about a disclosure that was going to keep e…
Earlier quoted context omitted.
We identified 3,438 unique domains. I'm not sure if those were all sent to Tavis because we were only sending him things that we wanted purged.
Are you guys planning to release the list so we can all change our passwords on affected services? Or are you planning on letting those services handle the communication?
Earlier quoted context omitted.
It is far from over, too! Google Cache still has loads of sensitive information, a link away! Look at this, click on the downward arrow, "Cached": https://www.google.com/search?q="CF-Host-Origin-IP:"+"author... (And then, in Google Cache, "view source", search for "authorization".) (Various combinations of HTTP headers to search for yield more results.)
> The infosec team worked to identify URIs in search engine caches that had leaked memory and get them purged. 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. The leaked memory has been purged with the help of the search engines. So I tried it too, and there's still data cached there. Am…
Someone pointed me to MALLOC_PERTURB_ and I've just run a few test programs with it set - including a stage1 GCC compile, which granted may not be the best test - and it really doesn't dent performance by much. (edit: noticeably, at all, in fact)
People who prefer extreme performance over prudent security should be the ones forced to mess about with extra settings, anyway.
And it shall be called Cloudbleed.
Earlier quoted context omitted.
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…
Earlier quoted context omitted.
If a user thinks the presence of "https" means it's safe to enter credit card details or medical information, that's already a huge problem. Yes, "https" should be a prerequisite to entering sensitive information, but that's only part of it; the other part is whether you actually trust the server you're sending that information to. The server could be using ironclad encryption across the whole connection, but that do…
It's always fairly safe to enter credit card details, you can chargeback that shit, type it wherever you feel like and just claim ignorance when it goes poorly. That's basically the whole point of using a credit card and not your bank account where you're liable for at least some of the money taken. No company is likely to handle your payment details completely securely. You're relying on it working out on sheer luck…