Re: Buffer overflow prevention

From: Crispin Cowan (crispin_at_immunix.com)
Date: 08/19/03

  • Next message: Crispin Cowan: "Re: PointGuard: It's not the Size of the Buffer, it's the Address" 
    Date: Mon, 18 Aug 2003 23:38:46 -0700
To: Theo de Raadt <deraadt@cvs.openbsd.org>

    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/
  • Next message: Crispin Cowan: "Re: PointGuard: It's not the Size of the Buffer, it's the Address"

    Relevant Pages

    • Re: Integration of ProPolice in FreeBSD
      ... The stack does not contain any of the "objects" that ProPolice ... run the same C code there which which we run on all other architectures. ... ProPolice will take a certain class of *actual* bugs in that C code, ...
      (freebsd-arch)
    • Re: lockup.zonelabs.com
      ... software and media piracy that they are writing protections into their ... I agree they have every right to protect themselves from illegal use ... And without adding more bugs to an already infested program! ... > I had a problem with ZoneAlarm always wanting to connect to the internet. ...
      (comp.security.firewalls)
    • Re: I got et up
      ... bodies to protect themselves from bugs. ... They just tolerate the bites ... As a related thing to the mud, I know concrete dust is a mosquito ...
      (rec.boats)
    • Re: How do I protect against rootkits
      ... cannot compromise any services running on my machine. ... buffer/heap overflows and some similar bugs). ... You can protect against ... The story changes for kernel bugs. ...
      (comp.os.linux.security)
    • Re: Avast silent mode problem...
      ... While there are ways (various privilege escalation exploits) to possibly get admin rights anyway, ... With drive encryption and preboot authentication as well as fresh updates, tight firewall and restrictive user accounts, it is very problematic unless you use quite sofisticated techniques like TEMPEST attack or something. ... Drive encryption wouldn't protect against malicious code on an running system... ... I'm talking about exploits using known bugs, to gain elevated privileges - or similar bugs not yet discovered, that may be in the future. ...
      (alt.computer.security)