Major security hole potentially affecting every site that uses Cloudflare was just made public:
The old QT3 used Cloudflare, didn’t it? What about this Discourse QT3?
Remember the days when every security leak didn’t have its own domain name or logo?
Yeah, we don’t particularly care about this one.
Cool. I just noticed this on Hacker News. Glad the forum isn’t affected. Was the main site?
Yes, but nobody logs-in so it doesn’t matter. The odds of anyone getting a logged-in admin cookie and knowing how to use it are astronomical. I changed all the salts anyway.
That’s unfair. This issue has none of the associated marketing campaign that security issues have been having for the last few years.
- It doesn’t have its own website. It has one spartan bug tracker entry and one disappointingly evasive blog post from Cloudflare.
- It doesn’t have a logo (that thing in the first message is something somebody unaffiliated probably threw together in Photoshop in 2 minutes).
- It doesn’t even have an official catchy marketing name. Except that the security researcher who found the issue wrote in the bug tracker: It took every ounce of strength not to call this issue “cloudbleed”, and other people apparently liked having some kind of name to refer to this with.
There is another reason to use a password manager. LastPass and 1Password both have features to let you know which of your accounts may need a password change. So far, though, I’m not reading anywhere that passwords were compromised.
That’s not what the guy who found it says:[quote]The blunder was first spotted by Tavis Ormandy, the British bug hunter at Google’s Project Zero security team, when he was working on a side project last week. He found large chunks of data including session and API keys, cookies and passwords in cached pages crawled by the Google search engine. These keys can be used to log into services as someone else.[/quote]
FYI: It doesn’t matter if you’re using a password manager or not. The bug meant that server memory was being spunked out into the web. Everything that could possibly be residing in memory is vulnerable, which includes all kinds of passwords and tokens. Hopefully the server only ever handled your password in an encrypted form, but that hashed password is still “loose” and is vulnerable.
Even things like OAuth tokens, like Discourse uses, can be used.
There are popular gaming sites on the change-your-password list, though:
Discord
Humble Bundle
Rock Paper Shotgun
plus maybe others. Those are the ones I’ve found so far scrolling through the incredibly long list of impacted sites.
I’d be less concerned about hashed passwords than saved session cookies.
If there’s passwords in there, they’ll be plaintext. Nobody transmits hashed passwords between the browser and the server as part of the login flow.
But yes, this would have leaked orders of magnitude more session cookies than passwords.
This is what really bothers me about password strength and how much importance is stressed about having a “strong” password. When really 9 times out of 10, even if you have an amazing password, it isn’t cracked by some encryption program, it is either the site being breached, and the unecrypted data being leaked, or someone social engineering their way into getting your password. Because, for hackers, the path of least resistance is likely just asking for the password and getting it.
What really matters is using reasonably strong unique passwords everywhere. That’s why everybody should use a password manager like Lastpass.
“I am not changing any of my passwords. I think the probability that somebody saw something is so low it’s not something I am concerned about.”
–Cloudflare CTO
Yes, if you read their detailed technical explanation, while the vulnerability extended back to September 2016, only a vanishingly small portion of their userbase was exposed as it required enabling the email obfuscation feature, server-side excludes (which are only enabled on sites under active attack) or HTTPS redirect in conjunction with another feature using their old parser, and email obfuscation was only on their new parser (and thus triggering the bug) for 5 days before CF fixed it.
So if your site had email obfuscation enabled, it’s possible you leaked some data between Feb 13 and 18. But actually not particularly likely, due to the several predicates required to hit the bug. That’s why only 0.00003% of CF requests were leaked.
This will definitely damage Cloudflare’s reputation, but it isn’t a massive danger to the integrity of the internet as a whole like Heartbleed was.
No, data for any site going through Cloudflare was vulnerable. (And it’s clear that they spent a lot of time writing that blog post to try to give people the impression that the impact from this was more limited than it actually was, while still technically telling the truth).
- A page is loaded for site X, with none of these features enabled
- Parts of the request or response remain in (freed) memory on the Cloudflare proxy server
- A page is loaded for site Y through the same proxy server. Site Y has these features enabled, and the page happens to fit the trigger conditions for the bug.
- The memory buffer used for the response is the same as the one as earlier used for X, and still contains that data. As a result of the bug, that data from site X gets written out as part of the response for the page load for site Y.
Ahh. Excellent point, you’re right. All those dependencies only apply for the site actually displaying the leaked data, not whether it was resident in memory in the first place.
It still isn’t a massive problem given the very small number of requests affected.