I want to make this perfectly clear. Although I am a webmaster, and someone who has been managing client websites for the past half-decade I am a designer. Not a computer scientist so I am writing semi-verbatim. If you’ve been linked this from a panicking client, please take a look at an official publication of errors, rather than relying on my account of the situation. I will be routinely updating this post as time continues, but it may be behind as I only blog for my own personal benefit, and it may not necessarily reflect the situation currently being experienced.

 

What is CloudFlare and why should I care?

CloudFlare is a content delivery network, and distributed DNS server that sits between the website host, and the browser. Unique to other offerings on the internet, CloudFlare handles the caching at a DNS level, rather than loading additional content from a specifically designed cache such as Amazon’s CloudFront, or Akamai. CloudFlare has also taken steps to configure applications such as Distributed Denial of Service (DDoS) protection, application firewalls, reverse proxy, and SSL certificates.

Founded in 2009, the service has jumped to widespread adoption due to its simple (once heralded as five minute) setup with sites such as ThePirateBay, Mozilla, Uber, OKCupid, and AddThis using the site’s services. In fact, I even utilise CloudFlare on this website to ensure the HTML and JS files are loaded from a cache. I have a different solution in place for images (Amazon’s CloudFront), but I do appreciate the simplicity of CloudFlare’s offerings. For the most part, I’ve been impressed with their offerings.

It’s safe to say that there’s quite a few websites that you visit on a daily basis that utilise CloudFlare in some way or another, so it’s likely you’ve given one of these sites your personal information.

 

What is a Buffer Exploit?

To understand this, we must first go back to how computers work at a binary level. Computers, or indeed servers in this case have a certain amount of allocated memory that they have for handling functions, and the for the most part. This is fine. Your computer, and the server are having a friendly back-and-forth conversation with each other; “I’m sending 14 bits”, “I am receiving 14 bits.” The problem comes however, when there’s a mismatch. When there’s too much data being sent to the server, and it continues to write this into memory. Normally, this will result in a crash. But not necessarily. If you’re smart about it, you can send commands, know what you want to get back… and take advantage of poor programming. Now, as I’ve said before. I’m just a webmaster, and I am not a programmer so I simplify a lot just for the sake of those reading my blog, but if you’re more of a visual learner. The YouTube channel Computerphile has a brilliant video on Heartbleed, the SSL Buffer Exploit that occurred in 2014.

 

What happened to CloudFlare specifically?

As I said before, CloudFlare sits between the user, and where the webmaster hosts. That means it gets to see almost all traffic coming to and from the user. That’s a fairly big responsibility, and again, for the most part, CloudFlare is very responsible about that trust they have with their users. The prime technology that allows CloudFlare to work is what’s called a parser. In sort, what this does is rewrite the content that is on your website with a version that CloudFlare can handle, in this case changing JS files to load from RocketLoader, rewriting non-HTTP connections, adding AMP functionality, and so forth.

A long term customer of CloudFlare, I have seen first hand the changes that they’ve gone through over the years, and the added features that have made that they have moved across to a new HTML parser. A routine, albeit big change that’s nothing out of the usual. The problem came in one single line of code that created something called a buffer overrun vulnerability. (The error involved a “==” in the code where there should have been a “>=”.)

On the 18th of February 2017, Tavis Ormandy from Google’s Project Zero reached out to CloudFlare after discovering that this buffer overrun was being stored in Google’s cache. In this case, it’s almost certainly a good-faith mistake on CloudFlare’s end, and we do have to thank the team at Google for investing in security research as well as responsibly disclosing this error to CloudFlare. According to CloudFlare’s official blog post, it took a total of three days with both their American, and London offices working on solving the error, with 0.00003% of requests likely affected as a result of this parser buffer overflow.

 

Should I panic?

No. As always it is a good precaution to change your passwords on a regular basis just in case you are pwned, and enable two-factor authentication on accounts that are particularly important to you such as your blog, financial services, social media, and so forth. I know many of you who are reading this right now might utilise the same password across multiple accounts and I cannot stress enough just how dangerous this can be in a time like this. In many ways, bering able to remember your password immediately puts you at risk as humans, by our very nature do not work well with complex passphrases such as “1hhh2k4$%@@” so we use short passwords, dictionary words, or substitute letters for numbers, or symbols.

I highly recommend switching away from this, and using a password manager such as LastPass. Even better, if you can avoid using passwords all together moving in favour for two-factor authentication, or other forms of security such as physical-swipe for machines can seriously reduce the risk that comes about with simple passwords. That’s not to say password managers are exempt from exploits, but the benefit here is that you can still change your services’ passwords, and maintain the same master password.

 

For developers

Buffer exploits are certainly one of the more common security issues we see now, owing to good development by higher order languages (with the notable exception of PHP…). That’s not to say we should ever be lazy with how we handle user data. My recommendation, as always to developers and clients alike is the best way to store user data is not to store it at all. If you can have Google, Facebook, Twitter, PayPal, Campaign Monitor, or whoever it may be handle your login and data storage you instantly reduce the risk of having data being accessed outside of it’s intended purposes.

 

For business people (i.e. Clients)

No matter what data you are storing, it should be treated as gospel, and you should treat those who detect bugs with quite a lot of respect. I know your first response might be to shut them down, and just pretend that the issue never happened, but this person has gone out of their way to report it (often in detail) to you to ensure that the service you are providing is secure. Develop a Vulnerability Disclosure Policy, and routinely enact penetration testing (which is required to be PCI compliant anyway) to  make sure you don’t having any gaping gaps in your security. I prefer to rotate through penetration testing providers on a regular basis to make sure that I’m not just getting the same result.

If there’s one thing I have to get cranky about when it comes to CloudFlare, is just how poorly they have returned the favour through their Hackerone programme. A T-Shirt? For solving a security problem? Really?