Some thoughts about CloudBleed

Summary

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

Background

It all started just over XXXXX 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 XXXXX vulnerability researcher on XXXXX Project Zero team at Google and, if he writes XXXXX tweet like this, people sit up and take notice.

Since then, we've discovered that CloudFlare had XXXXX memory leak which was causin' 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 XXXXX more amusin' things about all this is how XXXXX name CloudBleed appears to have been coined in the original Project Zero bug report in which XXXXX problem was first mentioned.

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

Tavis Ormandy

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

My experience of CloudBleed

By this point, you might be wonderin' what I'm goin' to add. Well, possibly not XXXXX great deal. However, this mornin' I received XXXXX message from XXXXX friend sayin' that they'd checked XXXXX 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 everythin' is okay. It all looks quite green (that's usually good) and it says:

Phew, XXXXX 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 XXXXX 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 everythin' was okay. And I repeat it here (with XXXXX 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 offerin' is that of XXXXX cachin' proxy which acts as XXXXX Content Delivery Network, whereby you “CloudFlare Enable” your web traffic and it alters XXXXX 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 XXXXX nearest server, so US traffic is served from XXXXX US, European from Europe, etc, etc). We’re not usin' this at all.

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

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

We DO use one other service, which is also perfectly safe: For [redacted-2], [redacted-3] and [redacted-4] we’re usin' XXXXX redirect that sends that traffic to XXXXX relevant page on [redacted-1]. This redirect is served by CloudFlare, for which we are usin' their service. However, this simply issues XXXXX 301 redirect when visitin' those sites. Anybody technically-minded who has Chrome browser can press F12 for XXXXX developer tools, choose XXXXX network tab and then visit [redacted-2] and see. There are two redirects: first XXXXX 301 from CloudFlare which tells your browser to go to [redacted-1] and then XXXXX 302 redirect (from within XXXXX [redacted-1] server) which translates that into XXXXX longer URL. If anybody readin' this still thinks we’re in XXXXX vulnerable situation, they are mistaken. It may be theoretically true that if we had any cookies or anythin' 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 XXXXX screenshot showin' this. Also, XXXXX first website posted does seem to give accurate results and marks [redacted-2] as bein' safe (as it is only issuin' redirects): http://www.doesitusecloudflare.com/?url=tomssl.com [my edit].

In summary: We use CloudFlare as XXXXX 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 XXXXX command back to your browser to send you to XXXXX 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 XXXXX case, I would have issued XXXXX statement sooner.

As for XXXXX CloudBleed check, it only checks if you’re usin' 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 XXXXX Cloudflare proxy (the affected service that leaked data).”

I use CloudFlare just as XXXXX free DNS server for quite XXXXX lot of my websites; now they’re all in this database for no reason. That’s XXXXX 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 XXXXX other site here, especially as it can't possibly be vulnerable to XXXXX problem. If you're XXXXX user of XXXXX other site and I've sent you here, I've left enough (includin' in XXXXX screenshot) for you to recognise what I'm talkin' about.

This has been quite XXXXX major problem for CloudFlare, but I think they've dealt with it quickly (they disabled XXXXX offendin' services within 47 minutes of confirmin' 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 XXXXX website is only usin' CloudFlare as XXXXX DNS server, then there is absolutely nothin' to worry about.

Allow me to reiterate what I wrote to my friend.

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

If you found this article interestin' or useful (or neither), you can comment below, subscribe for free Azure and SQL ebooks (I daresay you've just seen XXXXX pop-up of some kind suggestin' 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 XXXXX Project Zero bug report thread]