Slashdot Mirror
Cloudflare Leaks Sensitive User Data Across the Web (theregister.co.uk)
ShaunC writes: In a bug that's been christened "Cloudbleed," Cloudflare disclosed today that some of their products accidentally exposed private user information from a number of websites. Similar to 2014's Heartbleed, Cloudflare's problem involved a buffer overrun that allowed uninitialized memory contents to leak into normal web traffic. Tavis Ormandy, of Google's Project Zero, discovered the flaw last week. Affected sites include Uber, Fitbit, and OK Cupid, as well as unnamed services for hotel booking and password management. Cloudflare says the bug has been fixed, and Google has purged affected pages from its search index and cache. Further reading: The Register, Ars Technica
Ironically calloc would solve a lot of problems if only idiots would stop whining about how malloc is allegedly faster. It's ironic because Calloc begins with C.
As long as passwords are encrypted and decrypted on the client it's not really that much of a risk.
I think the benefit of having different complex passwords for every web/system with easy access from all devices is worth it. At least I havent managed to set up a better system for myself... yet.
MFA and a strong master password is pretty good for protecting your passwords.
Would not have helped. The problem with C is that pointers carry no information about the area of memory they're supposed to be point within. C programmers use pointers like indices, but an index alone isn't enough to address memory: You need the array too, and at least conceptually that comes with a size (but of course pure C doesn't stop you from exceeding array bounds.) What happened here is that the program had lots of buffers in contiguous memory, and by exceeding the one it was supposed to work with, it didn't end up serving uninitialized memory but other (initialized and used) buffers for other clients.
It's fine that you don't, but those of us who are aren't really worried. Client side encryption means not trusting the transport layer - even https.
No 1Password data is put at any risk through the bug reported about CloudFlare. 1Password does not depend on the secrecy of SSL/TLS for your security. The security of your 1Password data remains safe and solid.
https://blog.agilebits.com/201...
(I use LastPass myself)
The security I get from having unique 14+ char completely random passwords for _every_ site by far outweighs the slight possibility that access to both my encrypted binary as well as my master password slips out. The by far easiest attack vector for that would be hacking my systems, and if that happens any system I log on to can be snooped then and there as well.
it's in my head
Problem with 64-character passwords is that a lot of websites/services truncate passwords above a certain length, often without telling the user *cough* PayPal.
Um.. Considering the size and scope of Cloudflare, this pretty massive news.
And Cloudflare fixed it within 7 hours of learning about it. And the first thing Google did when discovering the bug was immediately reach out to Cloudflare. They went so far as to turning to Twitter to find the fastest possible route of alerting someone at Cloudflare.
But please continue to keep swearing about nothing.
I'm really surprised at the comments here. This is probably one of the largest information leaks/vulnerabilities of the past several years, and definitely the largest tech story of 2017. This is way larger than Google breaking SHA-1 (in a non-trivial way).
The HackerNews story has hundreds of comments explaining just how bad the situation is.
No, the worst part is when they perform the truncation on the web end and your 64 character password gets cut down before being processed, then at a later date they change the limit and your 64 character password gets cut down to a different length before being processed, thus preventing you from logging in. This can also happen if they decide to disallow certain characters and don't bother considering that user's may have them in their passwords already. It can also happen if they silently strip out certain characters but at a later date allow them.
SCE.com had this problem several times. In one instance, they fucked up on the truncation. Their limit was 16 characters but it was truly 15. My 16 character password stopped working. Kill off 1 character from the end, boom it works.
T-Mobile's site has had similar issues in the past.
I've even run into issues where the password reset tool accepts a length and character set that the login page doesn't, so even a freshly-set and accepted password won't work.
Yep, CloudFlare is spraying supposedly TLS-encrypted data all over the internet in clear text?! What the fuck!? I almost want to laugh at CloudFlare's misfortune, except every internet user including me is probably affected by this. What the hell is the point of HTTPS at all, when so much HTTPS traffic is being purposely MITM'd for profit by CloudFlare? A very large part of the web is living under their leaky roof, meantime many in the professional networking community encourage this and help implement it. Again I ask what the fuck!? The whole company smells more like a CIA operation as time goes on.
CLOUDFLARE IS UNDERMINING THE INTERNET, not to mention proudly serving ISIS terrorist websites, malware distributors, and DDoSers/Booters. They should be null routed and de-peered!
Part of what I do for a living, and have done for many years, is evaluate these kinds of vulnerabilities. This could have been really, really bad, a major story. Certainly it would be a big deal if all of the following were true:
If the issue existed for a long time.
If the bad guys knew about it before it was fixed.
If it affected sites that had something vaguely resembling valid html.
If it could have leaked tls/ssl keys.
In the security field, we have a mostly objective scoring system called CVSS which gives a numeric score to how bad the risk is. This scores high enough that it needed to be fixed right away - and it was fixed right away, probably before any bad guys knew about it.
Given the details of the issue, and how it was handled by first Google and then Cloudflare, I don't think it's the biggest story of the year. Cloudflare fixed it within hours and got cached copies of affected pages removed from search engine caches. All evidence indicates this was done before any bad guys were aware of the issue. I'm not too concerned. That's my professional opinion. My opinion would be different if it were left unfixed for six years after it was publicly known, then half fixed for six more years (looking at you, Microsoft).