After learning about buffer overflows: In the 90's finding a buffer overflow nearly always meant you could exploit it.

Nowadays there are a lot of protection mechanisms like address layout space randomization, making memory either executable or writeable, stack cookies, ...

It seems to me that with only 1 protection mechanism in place, you can get around it (for example with return orientated programming). But when you combine these protection mechanisms, the door is pretty much shut down. And if someone finds an overflowable buffer there is a 95 percent chance it's not exploitable.

It seems to me that the only way buffer overflows are reliably exploitable is if these protections are not in place, but operating systems force these protections

So are buffer overflow attacks pretty much dead nowadays?

  • The Heartbleed bug was not so long ago (2014). While this was not a typical buffer overflow bug in the sense that the bug caused the program to overrun the buffer while writing to it, it was in fact a buffer overflow bug in that the bug caused the program to read past the end of the buffer. See stackoverflow.com/questions/23089964/… – mti2935 Sep 22 '20 at 19:40
  • Your description of existing security mechanisms might reflect the user space of recent OS for server, desktop and mobile devices, but is far less applicable to OS kernel (including drivers) and smaller embedded systems. Also, running 20 year old software is not uncommon in industrial context, i.e. the terrible past is actually still present. But yes, buffer overflow is less used compared too all the other attacks. 20 years ago all the web based attacks did not matter that much as they do today. – Steffen Ullrich Sep 22 '20 at 19:45
  • 3
    This is just bad logic: "because something should not have a reason to exist, then, therefore, it does not exist". If you wanted to know if there were BO vulns, you can search for that. Here is a list of buffer overflow vulnerabilities found in 2020: cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow – schroeder Sep 22 '20 at 19:50
  • @schroeder While I agree that the logic is flawed I can understand if when your new to it and just learned about all that great stuff we have that you might think “surely this is a fixed thing now”. Your list of mitre conclusively proofs that to be false but I still get the thought pattern. – LvB Sep 22 '20 at 19:59
  • 1
    I have explained the flaw in logic. And your "95%/100%" comments are meaningless. Nothing is ever 100% and even 5% is enough to cause serious concern. – schroeder Sep 23 '20 at 6:44

While it is shocking, buffer overflows (alongside other memory corruption vulnerabilities) are still very much a thing of the present.

Due to exploit mitigations and hardening used by modern systems, it becomes much harder or impossible to exploit many of these vulnerabilities. However, many vulnerabilities are still introduced and/or found, as many new projects today are still written in unsafe languages, and many existing projects (e.g. Linux) written in these unsafe languages cannot easily be rewritten (yes, I'm aware there have been attempts to write kernels in Rust, but the language is probably very far from replacing the entire kernel codebase).

Anecdotally, I have found several buffer overflows this year in new code, or sometimes old code being reused for a new product. Some of them only amounted to denial of service, but others resulted in remote code execution. In some cases, it was easy to exploit them due to lack of exploit mitigations (e.g. many consumer-grade IoT devices have binaries compiled without mitigations), but other times, while more challenging, most of the mitigations could be circumvented.

In short, memory corruption vulnerabilities may never fully be eliminated as long as computer systems are not perfect; even a "safe" language can have bugs.


Buffer overflow (and under flow) will always exist. (Or at-least for as long as non memory safe languages are being used. Since assembly is memory unsafe and still needed to create same parts we still have the risk)

While we can employ protections against memory abuse (using a vm, memory safe languages like rust, compiler validation like in Golang.) there is no way know to us that can prove a piece of software is free from fault (this includes memory faults)

We must also consider that at many places we still can not use the tools we might like due too:

  • license issues
  • libraries in use
  • legacy code in use
  • processors in use
  • embedded environment limitations
  • Use of a fpga (which can not be programmed with much memory safe languages. But that’s a whole different story)

Tl;dr While it might seem that we should no longer have any memory issues there still impossible to completely eliminate.

  • The first part is plain nonsense. It's perfectly possible to write buffer-safe code in " unsafe" languages. It has to be, because CPU's execute "unsafe" assembly, yet it's possible for safe languages to exist. And in fact we do have software proofs. We even have an entire OS (seL4) kernel that's proven safe. – MSalters Sep 25 '20 at 9:57
  • Proof in this case would be mathematically in nature. I have not seen it and I have been taught due to the halting problem you can not have it. This is also part of why you can never be sure buffer overflows errors can not occur. While you can make it near impossible, making it completely impossible is not an option. – LvB Sep 25 '20 at 12:04

From my point of view, buffer overflows exists nowadays because you have old code running services everywhere. It is true that languages such as rust are focused on memory management and is difficult to exploit them, but there are other systems, for example, Apache Server that is written in C, that is potentially more impacted by overflows attacks.

On the other hand, overflows exist because of the way the operating system is designed with stack and heaps. I don't know right now any operating system that doesn't have these elements implemented on it.

  • The operating system I build for a 8088 did not use a stack or heap. So that’s atleast one that doesn’t. But you are correct that most systems use them. – LvB Sep 22 '20 at 20:02

There are 2 different points of view on your question.

  1. Can attackers rely on buffer overflow to find exploitable bugs ?

IMHO it is no longer the favorite tool of black hat hackers. Except on trivial (school) use cases, finding a buffer overflow requires a heavy job, and building an exploit above it still needs more work. There are many simpler ways by trying other well known bugs in various libraries, and even black hats know that the weaker security element for a computer lies between a keyboard and a chair... Social engeneering leads to cheaper ways...

  1. Is it still important to bore students with that ?

YES! Many parts of low level tools (OS, compilers, system libraries) have to use low level languages (assembly, C, low level C++). The strength of a software depends on the quality of all the underlying tools it uses, and the strength of a piece of code depends on the care of the programming team. As a now old dinosaur in the IT world, I have too often seen many codes where the security has not been a first class concern. That is the reason why it is still essential when teaching programming concepts, to insist on security best practices and the risk of not respecting them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.