In 2014, the Heartbleed bug made the data of millions of web-users publicly available to unauthorized third party access. When Cloudbleed leaked user info late last month, it seemed to some like deja-vu. Once again, private information like passwords, chats, hotel bookings and more were being casually sent random third parties. Even worse, the data was then being cached by Google and other Internet bots: it was a full scale security disaster once again.
Both Heartbleed and Cloudbleed are classified as buffer overflow vulnerabilities; a concept that is best described through a visual analogy. Think of software data storage as a series of small glasses, each of which can hold a small, specified amount of water, or data. Those glasses sit within a larger tub, which represents the main memory.
By being encased within a single glass, the water inside is protected from access by any of the other glasses. Everything inside the glass is safe—but remember, each one can only hold a certain threshold of water.
The problem arises when a request comes in that is too large for the glass it’s aimed at to hold. Think of it as a soda gun spraying water into the small glass: the container will hold some, but a huge wave of liquid will overflow into the larger tub. When that liquid is actually your private data, this becomes a problem.
You see, data in the main memory is completely unsecured. Anything can arbitrarily read or write into that space; meaning your data is easily accessed by third parties. Without the protection of a glass, there is nothing in place to keep your data private.
In the cases of both Heartbleed and Cloudbleed, the errors were the result of vulnerabilities, not malicious attacks. However, with the acknowledgement of how prevalent these vulnerabilities could be, it’s likely that we’ll see them exploited maliciously more and more going forward.
So how can we prevent these attacks in the future?
Unfortunately, the world of buffer overflow vulnerabilities isn’t really evolving. The reason for this is simple: almost all buffer overflows occur in code written in the C programming language.
On the surface, C is an excellent choice; it’s the highest performing coding language with well-optimized code in existence. However, the language’s major downfall is its age: it was invented in 1968. The C language was established in a time when data security wasn’t even a conversation, let alone a consideration. As such, there is no automation within the code to keep these types of vulnerabilities from happening.
What does overflow problems really mean?
Overflow problems come down to human error. In order to prevent each glass from overflowing, they must be manually checked for volume on a regular basis, and further data requests have to be monitored for size. If those checks aren’t performed regularly or one slips through the cracks, it’s impossible to stop the vulnerability from happening.
Today, there are new languages (like Rust) being developed that will make bonds-checks automated with very little effect on overall performance. However, these languages are still new and will take a while to catch on: meaning, it’s still up to humans to keep your data safe.
To date, only a purely vulnerability-focused security solution—like Cybellum—can effectively protect your data from these types of issues. As data becomes more valuable and these vulnerabilities present more and more risk of malicious attack, it’s imperative that you have dedicated security in place to ensure your information’s safety. Otherwise, your glass may overflow: and your data may end up all over the Internet.
Subscribe to get our vulnerability analysis posts, new blog content and very infrequent special announcements. We won’t spam you, and will never sell your data.
Did you find this interesting? Share it with others: