buffer overflow

[Nick Estes]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 23 Aug 2001, Lucas Vogel wrote:

> It seems as though every time I look at my favorite distribution's website
> (SuSE, in case you were curious) for software updates, there are a number of
> different security updates due to some kind of buffer overflow situation in
> one piece of software or another. Would someone care to go over buffer
> overflows, how they are exploited and good preventative programming
> practices?

Might as well start at the beginning; a buffer overflow is basically when
you shove more data into a buffer than you have allocated.

The rule of thumb is if at any time you are putting an unknown quantity of
data into memory, make sure there is no possibility that the data can
overflow your buffer. (ie use snprintf instead of sprintf)

Now for the question of how buffer overflows lead to security holes.  This
is the easy part since overflow exploits are all pretty much the same in
how they work.

Of course talk is cheap, so let's make a real security vulnerability with
a buffer overflow.  Grab http://nickstoys.com/overflow.c and compile it
with gcc (this assumes an x86 platform, it probably won't work on others).
Take a look at the source, if all goes well, we should run "/bin/echo
hello" twice; however, if you run the program, it won't because we
overflowed foo, it will some something different.  Now if you take out the
sprintf line and then uncomment the snprintf line and try it again, you'll
see that we got rid of the security hole.

Another varient on the theme is like what code red did; it stuck a bunch
of instructions in memory, and part of that overwrote a jump table which
caused the execution of the trojan code.

Hope that helps!

	--Nick
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/

iD8DBQE7herVv+hjYTGg7s4RAokLAJwPEKP1omQGE99uGfccT/HtI+KnhQCfXe+p
SMxIILOg9XvZzxflY33N8W0=
=teQ2
-----END PGP SIGNATURE-----