Sergey Nivens - Fotolia

Cloudflare security team calms fears over Cloudbleed bug

Cloudflare security researchers continue investigations as CEO calms fears over potential exposure of sensitive personal data by the Cloudbleed bug, though doubts remain.

Less than a week after initial reports of what was thought to be a devastating blow to end-user privacy caused by a subtle software vulnerability, Cloudflare's CEO posted a deep dive explanation of the incident to clarify -- and quantify -- the impact of the Cloudbleed bug.

Experts have praised the Cloudflare security researchers, Tavis Ormandy and Google's Project Zero for acting quickly to assess and mitigate the threat caused by the Cloudbleed vulnerability, as well as for Cloudflare's vulnerability disclosure transparency in explaining the causes of the threat as well as the possibility of exploitation.

What the Cloudbleed bug means

Noting that the question most often asked of the Cloudflare security team since the incident has been "what risk does Cloudbleed pose to me?" Cloudflare CEO Matthew Prince summarized the impact in a blog post titled "Quantifying the Impact of 'Cloudbleed.'"

"[W]hile the bug was very bad and had the potential to be much worse, based on our analysis so far," Prince wrote that Cloudflare hadn't found any evidence based on its logs that the bug was maliciously exploited before it was patched and that "the vast majority of Cloudflare customers had no data leaked."

After reviewing tens of thousands of pages of leaked data from search engine caches, Cloudflare security researchers "found a large number of instances of leaked internal Cloudflare headers and customer cookies, but we have not found any instances of passwords, credit card numbers or health records."

The most disturbing possible result of the Cloudbleed bug, which Prince called "the nightmare scenario," would have been if "if a hacker had been aware of the bug and had been quietly mining data before we were notified by Google's Project Zero team and were able to patch it," Prince wrote, though after reviewing Cloudflare security logs for nearly two weeks for evidence of active exploitation, Cloudflare "found nothing so far to indicate that was the case."

The Cloudbleed bug was caused by a latent flaw in an old HTML parsing program, which emerged and was identified only after Cloudflare began to replace it with a new parser. Under certain circumstances, interactions between the two parsers could cause exposure of data from uninitialized memory.

However, the one implication of the incident is that the exact data exposed is still uncertain. Prince wrote that the Cloudbleed bug is different from typical data breaches, where an attacker steals an organization's data: "The bad news in that case is that the robber has all your files. The good news is you know exactly what they have."

The Cloudbleed incident is more like having a stranger eavesdropping on employee conversations, where there are limits on the amount of data available to the eavesdropper -- but there is no way to even know what data may have been exposed.

"If a hacker were aware of the bug before it was patched and [were] trying to exploit it then the best way for them to do so would be to send as many requests as possible to a page that contained the set of conditions that would trigger the bug. They could then record the results. Most of what they would get would be useless, but some would contain very sensitive information," Prince wrote.

Cloudflare remediation strategy

So far, the Cloudflare security team reported that it had discovered personal data linked to approximately 150 Cloudflare customers in the 80,000 cached pages that were purged from search engines Google, Bing, Yahoo, Baidu, Yandex and others.

Prince wrote that Cloudflare has undertaken a full review of the HTML parser code that was the source of the Cloudbleed bug, and, in addition to that review, it is "working with the outside code auditing firm Veracode to review our code." The Cloudflare security team will also continue to work on expunging leaked data from third-party caches and analyzing its own logs for further clues.

There was another thing not always found in data breach reports: an apology.

"This bug exposed just how much of the internet puts its trust in us. We know we disappointed you and we apologize," Prince wrote. "We will continue to share what we discover because we believe trust is critical and transparency is the foundation of that trust."

Next Steps

Find out more about weighing vendor and customer needs in vulnerability disclosure

Learn about the right approach to defining a security vulnerability disclosure policy

Read about strategies for improving security in content delivery networks

Dig Deeper on Data security and privacy