Are buffer overflows pretty much a thing of the past in 2020

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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...

2. 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.