Are buffer overflows no longer a threat these days?

Question

After following buffer overflow examples and reading on them in various books/websites it seems there are lots of preventative measures in place to protect against them these days. ASLR, /GS flag security cookie, stack-protector in linux, etc, etc...

Some of the examples I have looked at give instructions on how to disable certain security features so that the examples will run...This seems like a really stupid idea to me - when running code against a real system you are not going to have the luxury of disabling its security features.

So what is the deal with buffer overflows these days, have them been rendered redundant by advances in security or are they still of use?

Answer 1

A lot of these countermeasures can be defeated by advanced exploitation techniques such as Return Oriented Programming (ROP). To answer your question, anti-exploitation techniques have made things much more difficult for a would-be attacker to exploit a buffer overflow but it's absolutely still possible and the severity of the consequences when one is successfully exploited is very high, as they typically allow arbitrary code execution.

Answer 2

Yes, they are of use, and yes, the protections are routinely turned off, off by default, or non-existant on various platforms.

To make the point explicit, I'm sure a modern product developed by smart people like Google Chrome would never have something as mundane as a buffer overflow. (Pick any word; those are just from 2011.)

---

EDIT To the question of why. Lots of answers. One simple one is that canaries only protect the return address, not the individual variables on the stack. Nor do stack canaries or non-executable stacks protect against heap-based overflows. If you have writable vtables (or any kind of function pointer), then attackers can rewrite your function calls on the stack or heap without touching the canary. There's a major performance trade-off for every additional protection you put in. And the stricter you make your execution environment, the more likely you won't be able to reuse legacy code without reworking it (and retesting it).

Attackers have to be more clever today than when Aleph One was writing about stack smashing. Some of the older attacks don't work widely anymore. But the basic idea of a buffer overflow has many forms, and many of those forms still work.

Answer 3

Three words: "Defense In Depth".

The meaning: The more you can do to prevent vulnerabilities, the better. Don't rely on any one thing (or even a couple of things) to protect you. They could be broken -- or, as you've seen, disabled.

Consider that even if you turn on all the paranoid security measures, if someone figures out how (or is lucky enough) to bypass any or all of the countermeasures put in place by your OS, then your only remaining defense is the correctness and robustness of your own code.

Plus, arbitrary code execution is just the worst of the worst as far as vulnerabilities go. Whether your broken code allows arbitrary native code execution or just crashes, that's still someone else causing your computer to do something it shouldn't, and potentially costing you lots of money.