Some thoughts about CloudBleed

Summary

CloudFlare had a really bad memory leak, but they've fixed it now. At the time of writing, some sensitive data may still be in some search engine caches. It's being removed as it's being found.

Background

It all started just over a week ago with this simple tweet from Tavis Ormandy.

Could someone from cloudflare security urgently contact me.

— Tavis Ormandy (@taviso) February 18, 2017

Tavis is a vulnerability researcher on the Project Zero team at Google and, if he writes a tweet like this, people sit up and take notice.

Since then, we've discovered that CloudFlare had a memory leak which was causing web pages to have sensitive information from other websites embedded in them accidentally. Worse still, some of this data had been cached by search engines. That's pretty bad.

One of the more amusing things about all this is how the name CloudBleed appears to have been coined in the original Project Zero bug report in which the problem was first mentioned.

(It took every ounce of strength not to call this issue "cloudbleed")

Tavis Ormandy

In the last few days a vast amount has been written about this. Amongst those articles worth reading are this from The Register and this pragmatic piece from Troy Hunt. There's a decent incident report from CloudFlare themselves which you should also read.

My experience of CloudBleed

By this point, you might be wondering what I'm going to add. Well, possibly not a great deal. However, this morning I received a message from a friend saying that they'd checked a site for which I'm responsible and had received contradictory reports and could I elaborate.

To save any embarrassment, let's use this site as an example.

If you go to http://www.doesitusecloudflare.com/?url=tomssl.com you will see that everything is okay. It all looks quite green (that's usually good) and it says:

Phew, the website does not use cloudflare!

However, if you go to https://cloudbleedcheck.com/?domain=tomssl.com you will see an angry red background (that can't be good) and a message saying

This domain is affected

Close all active sessions for this service, change your passwords, and enable 2FA.

This is unnecessary, inaccurate and irresponsible.

And so it was that, early on Saturday morning, I had to write an explanation of why everything was okay. And I repeat it here (with a few minor redactions).

Here is what I told my friend (edited slightly)

We are not affected, it’s fine. Here’s why:

We DON’T use this: CloudFlare’s main business offering is that of a caching proxy which acts as a Content Delivery Network, whereby you “CloudFlare Enable” your web traffic and it alters the DNS records so that all web traffic hits their load balancers first and is then dealt with accordingly by them. This means that they serve up requests from within their cache (and also from the nearest server, so US traffic is served from the US, European from Europe, etc, etc). We’re not using this at all.

We DON’T use this, either: CloudFlare also offer free SSL certificates, which require that your traffic also be served in the same way as above. That’s part of the reason this is causing people to freak out; their SSL traffic might be compromised. We’re not using that, either.

We DO use this: Another thing you can do with CloudFlare (which they don’t really advertise as it’s free) is just to use them as a DNS host. I’m sure most of you know that all a DNS host does is act as the definitive resource so that when somebody wants to visit (for example) [redacted-1], it tells them which IP address that resolves to. This is the only thing we’re using for [redacted-1].

We DO use one other service, which is also perfectly safe: For [redacted-2], [redacted-3] and [redacted-4] we’re using a redirect that sends that traffic to the relevant page on [redacted-1]. This redirect is served by CloudFlare, for which we are using their service. However, this simply issues a 301 redirect when visiting those sites. Anybody technically-minded who has Chrome browser can press F12 for the developer tools, choose the network tab and then visit [redacted-2] and see. There are two redirects: first the 301 from CloudFlare which tells your browser to go to [redacted-1] and then the 302 redirect (from within the [redacted-1] server) which translates that into the longer URL. If anybody reading this still thinks we’re in a vulnerable situation, they are mistaken. It may be theoretically true that if we had any cookies or anything at [redacted-2], [redacted-3] or [redacted-4] they might feasibly be at risk of compromise (I’m not sure), but we don’t use cookies on those domains. I have included a screenshot showing this. Also, the first website posted does seem to give accurate results and marks [redacted-2] as being safe (as it is only issuing redirects): http://www.doesitusecloudflare.com/?url=tomssl.com [my edit].

In summary: We use CloudFlare as a DNS server, so it translates friendly domain names into IP addresses. For [redacted-2], [redacted-3] and [redacted-4] only we use CloudFlare to issue a command back to your browser to send you to the relevant page on [redacted-1]. We don’t use any of their other services. No caching, accelerating, SSL certificates, etc, etc. We are definitely safe.

Had this not been the case, I would have issued a statement sooner.

As for the CloudBleed check, it only checks if you’re using CloudFlare as your DNS server. They even state that here: https://github.com/pirate/sites-using-cloudflare

"This list contains all domains that use Cloudflare DNS, not just the Cloudflare proxy (the affected service that leaked data).”

I use CloudFlare just as a free DNS server for quite a lot of my websites; now they’re all in this database for no reason. That’s a shame.

Conclusion

I'm sorry about all those redactions (which probably makes it look like I've got delusions of grandeur), but it's not my place to mention the other site here, especially as it can't possibly be vulnerable to the problem. If you're a user of the other site and I've sent you here, I've left enough (including in the screenshot) for you to recognise what I'm talking about.

This has been quite a major problem for CloudFlare, but I think they've dealt with it quickly (they disabled the offending services within 47 minutes of confirming that they were affected) and sensibly (full disclosure in their blog post). And they have fixed it. If you're concerned, you might use this as an opportunity to change various passwords but, if the website is only using CloudFlare as a DNS server, then there is absolutely nothing to worry about.

Allow me to reiterate what I wrote to my friend.

I use CloudFlare just as a free DNS server for quite a lot of my websites; now they’re all in this database for no reason. That’s a shame.

If you found this article interesting or useful (or neither), you can comment below, subscribe for free Azure and SQL ebooks (I daresay you've just seen a pop-up of some kind suggesting you might like to do so. Click here to see it again. I promise not to pester you and you might even win something) or follow me on Twitter (I'll probably follow you back). Follow @TomChantler

[Image Credit: seclogodesigner from the Project Zero bug report thread]