Date: Mon, 18 Aug 2003 23:38:46 -0700
From: Crispin Cowan <crispin@...unix.com>
To: Theo de Raadt <deraadt@....openbsd.org>
Cc: mtinberg@...urepipe.com, bugtraq@...urityfocus.com,
	peter@...steddebian.org
Subject: 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/

Powered by blists - more mailing lists