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/
This archive was generated by hypermail 2b30 : Tue Aug 19 2003 - 12:04:37 PDT