4 ms·
I don't see anywhere in the post where they claim private data wasn't leaked. In fact, they explicitly state that authorization cookies were leaked. What they s
by eridius 10y ago
I don't see anywhere in the post where they claim private data wasn't leaked. In fact, they explicitly state that authorization cookies were leaked. What they said they didn't find was passwords, CC info, health records, SSNs, and customer encryption keys.
They even have a paragraph talking specifically about cookies in GET requests:
> This is not to downplay the seriousness of the bug. For instance, depending on how a Cloudflare customer’s systems are implemented, cookie data, which would be present in GET requests, could be used to impersonate another user’s session. We’ve seen approximately 150 Cloudflare customers’ data in the more than 80,000 cached pages we’ve purged from search engine caches. When data for a customer is present, we’ve reached out to the customer proactively to share the data that we’ve discovered and help them work to mitigate any impact. Generally, if customer data was exposed, invalidating session cookies and rolling any internal authorization tokens is the best advice to mitigate the largest potential risk based on our investigation so far.
- tedunangst 10y agoIt's still weird to enumerate things not found, but no mention of examples like dating site messages that were found. They're obscuring that by focusing on internal headers, etc. Why does the table with "0 health records" not have an entry for "X private correspondence"?
- 79d697i6fdif 10y agoMy biggest issue is that they didn't release their data-set. With something this major, it's standard to either have a third party investigate or publicly release your data so it can be validated. For all we know they cherry picked the responses they tested from a single site that doesn't handle anything sensitive.
- eridius 10y ago> For all we know they cherry picked the responses they tested from a single site that doesn't handle anything sensitive. I don't think you understand how Cloudbleed works. It doesn't matter what site they picked; every single vulnerable site can leak the exact same info. It's literally impossible to cherry-pick that data.
- 79d697i6fdif 10y agoI don't think you understand how the internet works. Some websites only serve static content and don't deal with any sensitive information. Without seeing Cloudflare's data set there is no way to verify that the responses they picked are a representative sample.
- eridius 10y agoOk you really don't know how Cloudbleed works. Go read up on it. Every single vulnerable site can and did leak the same information. The only way to "cherry-pick" it would be to literally throw away the responses that you saw and didn't like, or in other words, by lying.
- lnanek2 10y agoI think he was trying to explain to you that, for this particular leak, what was leaked was the private memory of the CloudFlare servers. So that memory doesn't have all a single site in it. It doesn't matter what site triggered the data to be output, the data that was output can still come from any CloudFlare customer even if they had no pages with the condition that triggered the issue.
- eridius 10y agoThere's 3 classes of information: 1. Information where improper disclosure is illegal. For example, health records. Or credit card details, which would presumably be a violation of PCI DSS. 2. Information that can be actively exploited, but can also be fixed so the previous disclosure is harmless. This means passwords, authentication tokens, etc. 3. Information that is merely private in nature. Cloudflare is focusing on the first two items. The third one is hard to quantify; what one person may consider private, another person might not care about. And there's not much that can be done about this kind of disclosure (beyond scrubbing caches which they're doing anyway). Also, it's difficult to automatically identify this type of content (whereas cookies, passwords, credit card numbers, etc are pretty easy to detect) and Cloudflare probably doesn't want to have their employees spending their time reading through all of the cached data they can find looking to see if there's private info (both because it's a lot of work and a huge waste of time since it won't affect anything, and because it's private info; chances are nobody's going to see it normally, and having employees reading your private messages doesn't help anyone and is a violation of your privacy).
- tedunangst 10y agoPlus a 4th class: public information. I don't know how they could determine how many health records were leaked without looking at and classifying the data, so they've already gone ahead and done that. They presumably know how many steamy Grindr messages were in there. Additionally, there are laws about messages as well. Email laws generally don't specify smtp only.
- eridius 10y agoHealth records probably have some sort of health record ID, and there's only so many formats that can take. Detecting strings that match certain ID patterns is easy.
- tedunangst 10y agoThat's one hell of a busted test. So a page fragment could leak my name and "hurts when I pee" but if the universal standard ID was cutoff it's not a health record?
- 79d697i6fdif 10y agoCloudflare mentioned they only went through about 2000 leaked responses out of over a million. That combined with random people on hackernews STILL finding private data after the purge points towards this leak being a lot worse than they're letting on. Thankfully CloudFlare spent a week cleaning up the leak in search engines and caches before publicly announcing the issue, so a lot of the evidence is gone.