CloudBleed

CloudBleed – Eggs in the Basket and the Basket Tipped Over

Hopefully you have been following the CloudBleed bug discovered (and now fixed) by ProjectZero team. Here are the details incase you haven’t yet seen it.

What is CloudBleed
CloudBleed is a major information leakage bug in CloudFlare’s CDN. The bug is responsible for leaking very sensitive information including but not limited to passwords, encryption keys, security tokens, private conversations and much much more.

Is the Bug Related to HeartBleed
Not really. The name is derived from HeartBleed. It is similar in impact but it not a SSL/TLS issue.

About CloudFlare
In one line, CloudFlare is a large content delivery network that provides DDoS protection, Web Application Firewall, DNS, and CDN service.

Who is Impacted
According to CNET there are about 3400 websites that use CloudFlare https://www.cnet.com/how-to/cloudbleed-bug-everything-you-need-to-know/. According to CloudFlare’s post 161 unique domains were known to be impacted. It is not obvious based on the post if this is the full extent of the impact.

How Big is the Impact
This is really hard to say. According to Tavis Ormandy who was primarily responsible for finding and reporting this, the bug has inadvertently allowed crawlers to download sensitive information. Given the un-deterministic nature of the issue it would be very hard to determine what was downloaded by which crawler. Accordingly to CloudFlare, they have worked with search engines to purge the leaked memory. With that said, there are hundreds of active crawlers on the Internet. Here is a quick list I could find http://www.user-agents.org/. The real impact will depend on how many crawlers got the sensitive information.

Simplicity of Issue
If you are looking for the exact details of the bug I recommend reading the CloudFlare article https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/. They deserve high marks for transperency. The short version is

Vulnerable Code

if ( ++p == pe )
goto _test_eof;

The pointer p jumped over the end of buffer when the web page being processed had broken html tags. A check with >= instead of == would have solved the issue.

How Common are these Bugs
Ask most engineers and bugs like this are fairly common. In most cases a bug like this results in a benign exception. Code bases have issues like this all over. It is rare when an issue like this has a wide impact like CloudBleed. As rare as it may be, the possibility exists and when it does happen it can cause a massive breach.

What Next
My personal take is that we are in an immature stage of security maturity. A single, simple bug has the capability to dump massive amounts of sensitive information. It was true of HeartBleed and is also true of CloudBleed. Similarly, a compromise of a single root/administrator account can compromise the whole enterprise. We are moving (very slowly) towards the goal where this not going be possible. For now, overall technology is very fragile and vulnerable.

Huge ShoutOut
In my biased view, teams like ProjectZero (and security researchers all over) are doing a major public service. They identify and help correct issues before any malicious entity finds and exploits them. The issues exist and continue to proliferate. The good intentioned security researchers keep us safe. Give them a high-five over ether.