does buffer overflow still exist?

2
votes

I was watching a university lecture about buffer overflow, and the professor ended up saying

even if we were able to fill the buffer with exploit code and jumped into that code, we still can not execute it..

the reasons - he mentioned - are:

  1. programmers avoid the use of functions that cause overflow.

  2. randomized stack offsets: at start of program, allocate random amount of space on stack to make it difficult to predict the beginning of inserted code.

  3. use techniques to detect stack corruption.

  4. non-executable code segments: only allow code to execute from "text" sections of memory.

now I wonder, does buffer overflow attack still exist nowadays? or it is out-of-date.

detailed answer will be very appreciated!

1
clinuxsecuritybuffer-overflow
The problem will always exist. – squiguy
1 is patently false. They should, but not all do. 2, 3, and 4 are OS- and architecture-dependent. – Ignacio Vazquez-Abrams
It's harder to exploit it, but the problem exists. Just because it's an old issue, it doesn't magically disappear as time goes by. – Filipe Gonçalves
(3) is very unreliable in most implementations. (4) is incomplete: the idea is that memory sections are either executable or writable, but never both. – kay
Non-executable stack doesn't save you. See return-to-libc/ROP-style techniques. Randomized library adresses help mitigate this, but often enough people find ways to predict these adresses using different vulnerabilities prior to triggering a stack or heap-based buffer overflow – Niklas B.

1 Answers

9
votes

  1. Not all of us. There's a bunch of new programmers every day. Does our collective knowledge that strcpy is bad get disseminated to them magically? I don't think so.

  2. Difficult, yes. Impossible, no. Any vulnerability that can be turned into an arbitrary read can defeat such protections trivially.

  3. Indeed we can detect stack corruption, under certain circumstances. Canaries, for instance, may be overwritten, their value is compiler dependent, and they might not protect against all kinds of stack corruption (e.g. GCC's -fstack-protector-strong protects against EIP overwrite, but not other kinds of overrun)

  4. W^X memory is a reality, but how many OS's have adopted it for the stack? That'd be an interesting little research project for your weekend. :) Additionally, if you look into return-oriented-programming (ROP) techniques (return-to-libc is an application of it), you'll see it also can be bypassed.