OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Buffer Overflows and DoS
From: Horst von Brand (vonbrandinf.utfsm.cl)
Date: Thu Apr 27 2000 - 16:12:38 CDT

Crispin Cowan <crispinwirex.com> said:
> Horst von Brand said:

[...]

> C has no native notion of strings at all. C has character pointers and
> pointer arithmetic, but no strings at all. The entire string notion in C
> comes from an idiom embodied in the C standard library. Bernstein has
> provided an alternative string library.

The standard C library _is_ part of the language. As is "a string".

[...]

> > Besides, how you keep track of the length
> > of your strings is irrelevant, you have to check bounds.

> It's not irrellevant. If you use a base+bounds notation, then it is easy
> to create library functions that CORRECTLY do bounds checking on the size
> of the destination buffer, because the size of the buffer is encoded in
> the string object. With the null terminated idiom, the code has no easy
> way to determine the size of the receiving buffer, which is what makes
> doing correct bounds checking in C programs hard.

Hummm... so I go and do the moral equivalent of:

  s1 = "Hi!";
  s2 = "Hello, world!\n";
  s1 = s2;

Now, the contents of s1 is 3 characters long. How do I know if the
assignment s1 = s2 is valid, without knowing what s1 is able to hold in
characters? You just said knowing this "3" above is enough. You need the
size of the container and of the containee here.

> > And that would
> > mean an extra two words for each and every string (one the length of the
> > array, another the current length). 8 bytes extra for "foo".

> That was no doubt what Kernighan & Ritchie were thinking in the late
> 1960s when they were designing this stuff for PDP 8 machines, with 8 KB
> of RAM. Palm pilots now commonly have megabytes of RAM and workstations
> can have gigabytes of RAM. Fussing over an extra word is penny wise and
> pound foolish.

That machines are bigger now just means that people demand to solve even
much bigger problems with them. No spare memory or CPU power available,
really. Least of all in servers, i.e., security-critical programs.

> The major barrier to using Bernstein's library is that you end up re-writing
> software to do it. But new code would well benefit from using DJB's string
> library instead of the standard string library.

It is a _very_ high barrier if you can't write standard C anymore.

> > No. Functions that are called with a buffer elsewhere as arguments abound.
> > That such attacks aren't widespread is just result of the fact that
> > machines with stacks that grow upward aren't that common.

> But it's still harder to do. Attackers started with the easy stuff, and
> move on to the harder stuff when the easy stuff is mined out.

Stack growing upwards isn't as attractive to smash as there are very few
machines around doing it. Non-executable stack smashing is at best
marginally harder, so the protection it affords is minimal.

[...]

> Note that there is no way to jump over the StackGuard defense: you have
> to go find a different bug to exploit.

Instead of getting root, the attacker DoSes the server by crashing it
repeatedly. Much better, but by no means ideal.

[...]

> > But it only notices that the cage is open when the bird is long gone,
> > so it isn't a solution for everything.

> I'm not sure what you mean by the above analogy. StackGuard halts the
> attack in progress. The attacker never gains any privilege.

The attack has succeeded in overwriting memory it shouldn't have
touched. You notice this long after the overwriting (when returning).
Besides, smashing a variable after the buffer (without touching the
canaries at all) could be exploited too.

> > Ideal would be for the compiler (or a
> > lint-like tool) check array bounds at compile time, and warn each time it
> > can't prove bounds won't be overrun. But to get the noise level down to
> > bearable seems to need much more work still. And C's convoluted semantics
> > and laisez-faire with types certainly doesn't help a bit here.

> Check out this excellent paper by Wagner
> http://www.cs.berkeley.edu/~daw/papers/overruns-ndss00.ps from his
> impressive page of publications http://www.cs.berkeley.edu/~daw/papers/ .
> It describes work on a tool to analyze C programs looking for buffer
> overflows. This is some of the most advanced work available on automatic
> detection of buffer overflow vulnerability in C code, and still it has a
> high rate of fales positives, and does not catch all potential buffer
> overflows. That's because static analysis of C code for buffe r
> overflows is undecidable: no amount of work will ever get this perfect.

Right. OTOH, running something like this for security-critical code, and
then checking by hand where it can't do it automatically will eliminate
most thinkos. 

-- 
Dr. Horst H. von Brand                       mailto:vonbrandinf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513