[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Buffer overflow prevention



Theo de Raadt wrote:

and intrusion prevention technologies.
I translate this to mean that when some random bug does exist, system
features exist which decrease the ease with which it can be exploited.
ProPolice, StackGaurd, non-executable objects, random object addresses
-- these kinds of things fall in that area.

Agreed.

I just want to tease him for choosing ProPolice instead of StackGuard without so much as talking to me :)
Hah, on the contrary, I chose ProPolice because I had talked to you [StackGuard did not find bugs]

That's a very peculiar complaint, which is inconsistent with the purpose of StackGuard: it is an intrusion prevention technique, not a debugging technique. If you want to go hunting for buffer overflows, use either a static analysis tool like RATS, or a dynamic analysis tool like Fuzz. Fuzz-like tools will slam programs with big strings, causing them to seg fault where buffer overflow bugs appear. StackGuard and ProPolice only slightly enhance the diagnostic output when you get a hit, and do nothing at all to help find more bugs.

Since we incorporated ProPolice into OpenBSD, we have found many bugs
of this ilk.  We've even found 2 buffer overflows inside our kernel.

These were not as such security holes per se, but just bugs.  This means
the technology is working.

It means no such thing. StackGuard and ProPolice have exactly the same (weak) ability to detect buffer overflow bugs. If you found bugs with ProPolice and not with StackGuard, that means only that you tried with ProPolice, and did not try with StackGuard.

You might respond that it is my job & not yours to try with StackGuard, We have not done that, because StackGuard is completely the wrong tool to use for such a bug hunt. None the less, if it helps you understand, we have found two trivial bugs with StackGuard:

  1. iwconfig (WiFi network configuration tool) had a bug that
     triggered a StackGuard alert when the program exited. Something
     was doing a buffer overflow that corrupted an activation record
     just as the program terminated, so it was a non-fatal error.
     iwconfig is not privileged and the error probably occurs too late
     to exploit, so we did not bother to report it.
  2. glibc has a fault in its self-test bootstrap
     http://sources.redhat.com/ml/bug-glibc/2002-05/msg00766.html  This
     too was insignificant, because Ulrich had already found and fixed it.

"How many bugs have you found with this tool?" is just a silly metric for measuring intrusion prevention technologies. I understand that bug hunting is your primary modus operandi, but just because you're really into pounding nails does not mean that every tool should be evaluated for its applicability as a hammer.

OTOH, here's a metric for you: ProPolice lets buffer overflows through:

obsd# uname -a
OpenBSD obsd.int.wirex.com 3.3 GENERIC#44 i386
obsd# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-unknown-openbsd3.3/2.95.3/specs
gcc version 2.95.3 20010125 (prerelease, propolice)
obsd# cat fail.c
#include <stdio.h>
#include <unistd.h>

int foo(char *blah) {
 char buffer[7];
 sprintf(buffer, "12345678901234567890123456789012345678901234567890");
 return(1234);
}

int main(int argc, char **argv) {
 printf("before foo()\n");
 foo("blah");
 printf("after foo()\n");
}

obsd# gcc -fstack-protector -o fail fail.c
obsd# ./fail
before foo()
Segmentation fault (core dumped)

ProPolice does not protect functions containing arrays of length 7 or less. We don't know what other cases exist in which ProPolice fails to protect. This kind of risk exists precisely because of the design choice that gives ProPolice its multi-architecture capability: putting the protection way up high in the compiler. This creates the potential for later stages of GCC to optimize away the security checks, or move them so far away from relevant code that they are no longer effective. When you choose ProPolice, you choose CPU portability over security.

OTOH, I like the variable sorting hack in ProPolice, and thought about implementing it, but chose instead to concentrate on PointGuard, which protects all of the cases that ProPolice variable sorting protects, and then some.

Crispin

--
Crispin Cowan, Ph.D.           http://immunix.com/~crispin/
Chief Scientist, Immunix       http://immunix.com
           http://www.immunix.com/shop/