Vulnerabilities A Story — Buffer Overflow

This short blog will introduce one of the most common vulnerabilities reported for the last 21 years[1] since the Common Vulnerabilities and Exposure database/site (CVE) was launched, Buffer Overflows. To provide a little bit of context lets go over some CVE trivia. The second-ever reported vulnerability recorded in the CVE database was CVE-1999–0002, buffer overflow in NFS mountd[2]. In 2020, 21 years after the Buffer Overflow in NFS was reported, there have been hundreds if not thousands of buffer overflows reported[3]; eg. the first buffer overflow reported in 2020 was CVE-2020–0032, heap buffer overflow in ih264d_release_display_bufs of ih264d_utils.c that could lead to remote code execution[4], and the latest reported at the time of writing this blog, CVE-2020–9760, buffer overflow in WeeChat versions 0.3.4 to 2.7[5].

There are 21 years of reports, coding and compiler improvements, system improvements to the point that buffer overflows should have been totally eradicated, yet it is still a commonly reported vulnerability; the question I asked myself is how can this be?

In accordance to OWASP:

“A buffer overflow condition exists when a program attempts to put more data in a buffer than it can hold or when a program attempts to put data in a memory area past a buffer. In this case, a buffer is a sequential section of memory allocated to contain anything from a character string to an array of integers. Writing outside the bounds of a block of allocated memory can corrupt data, crash the program, or cause the execution of malicious code.”[6]

In essence think of a buffer overflow like a bucket that is being filled with water, a well-managed buffer would stop the water before it is full and leave a little bit of padding, a bad buffer will just keep pouring water until it spills out of the bucket making a mess of the floor.

Buffer overflow’s occur because of a lack of data sanitisation, specifically, boundary checks; to prevent it, the best solution is to perform boundary checks on all requests made by the user and application. OWASP recommendation is as follows:

“Keep up with the latest bug reports for your web and application server products and other products in your Internet infrastructure. Apply the latest patches to these products. Periodically scan your web site with one or more of the commonly available scanners that look for buffer overflow flaws in your server products and your custom web applications. For your custom application code, you need to review all code that accepts input from users via the HTTP request and ensure that it provides appropriate size checking on all such inputs. This should be done even for environments that are not susceptible to such attacks as overly large inputs that are uncaught may still cause denial of service or other operational problems.”[7]

OWASP, of course is focused on web applications, but this recommendation applies to all applications, for custom-developed applications, most software nowadays have very well tested and proven buffer overflow protections, implement them and make sure the software is penetration tested by a professional pentester from an accredited organisation.

A good guide for software developers would be to adhere to the Software Secure Development Life Cycle, there are multiple sources on how to implement this and that would be the topic for another blog.

For the time being, I will leave it here with a few useful links:

Vulnerability tracking:

Buffer Overflow General Information:

Software Secure Development Life Cycle:

I have been in the pentesting business for a few years now, the thing that I find the most amusing is how many large well-respected corporations do not follow any security practices. Recently, in a meeting with a large global corporation that provides services to vital corporations (don’t ask, they will all stay nameless), I was asked by their developers why they should fix these vulnerabilities. They said that we were the only client complaining about it, I must admit I lost it a little bit, and I had a big go at them for their irresponsible posture particularly for the risk they put their clients at, we are talking about millions if not billions at risk, let’s just say now their stance is a little bit more responsible and they are fixing the issues.

What I hope people take from this little story is that it doesn’t matter how big the corporation behind the software is, never assume they are safe, always pentest or at the very least scan to ensure at the very least they have covered the low hanging fruits, such as buffer overflows.

Buffer overflows are one of those vulnerabilities that should no longer exist, there are enough information and preventions to ensure it is no longer present in any application, it is also one of the biggest vulnerabilities, with the best results. I hope this blog has highlighted the dangers of buffer overflows, the commonality of them and the importance of penetration testing and scanning to ensure they are not present.

Thank you to my friends Braam Broodyck, Jack Gifford and Sherry Liu for reviewing, editing and helping me make the blog better.