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?

  • 7
    A buffer overflow means programmer incompetence. It is arguable whether incompetence is still a threat. Java and C# want to tell you that it isn't, but only history will be the judge.
    – Kerrek SB
    Jan 12, 2012 at 2:09
  • I think he was rather asking if the countermeasures taken would nullify the risked caused due to incompentence.
    – Uku Loskit
    Jan 12, 2012 at 2:11
  • 2
    @Uku: The thing about incompetence is that it eventually overcomes all countermeasures.
    – Kerrek SB
    Jan 12, 2012 at 2:13

3 Answers 3


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.

  • How are these buffer overflows possible in this day and age...why are the likes of google putting out software that has buffer overflow protections 'turned off'? I just dont get it, I can see how there is any excuse for buffer overflows when the protections have been around for years now. The /GS flag security cookie, for example, has been in visual studio for at least a decade now...
    – John McDonald
    Jan 12, 2012 at 2:24
  • 4
    /GS can't protect you against every kind of buffer overrun. For example, it only operates on string arrays, not arrays of structures. It can't protect you against pointers that walk off the end of stack variables which are not arrays or _allocas. It can't protect you in variadic functions. It can't protect you from heap overruns.
    – Crashworks
    Jan 12, 2012 at 2:28
  • Does the Chrome team use VS? I'da figured them for a cross-platform-compiler kind of group...
    – cHao
    Jan 12, 2012 at 2:29
  • Yes, Chrome is built with VS, like most projects that run on Windows, and Xcode on Mac and Make on Linux as you'd expect. Being properly cross-platform means you can use different compilers and still have it work. chromium.org/developers/how-tos
    – Rob Napier
    Jan 12, 2012 at 2:51

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.