Buffer_Overflow by zhangyun

VIEWS: 12 PAGES: 21

									Anatomy of the
Buffer Overflow


      Adam Chapman
      Stephen Hines

      Tuesday April 1, 2003




                              back   next
Introduction

        A buffer overflow is like trying to put ten
         pounds of sugar into a container that only
         holds five pounds. Once the container
         fills, the rest spills all over the counter
         and floor, making a mess.
        Buffer overflows occur mainly because of
         C language libraries and partially
         because of poor programming practices.
        The C language libraries are not going to
         change, but programming practices could
         undergo some improvement.

                                               back    next
Framework


       The C language is a structured
        programming language.
       Structured programming languages
        use the function call as their unit of
        organization.
       While the designers of C were
        smart in designing a structured
        language, they also created the
        framework for buffer overflows.

                                          back   next
The Stack

        Each time a function is called, arguments
         to the function get copied to an area of
         memory called the stack.
        You store things on the stack by pushing
         them on, and retrieve them by popping
         them off the stack.
        All CPU architectures currently in use
         support the notion of a stack and have a
         special register (the stack pointer) and
         operations for pushing and popping.


                                              back   next
The Stack


        There is an operator that takes an
         address off the stack and copies it
         into the program counter,
        The program counter is a register
         that determines the address of the
         next instruction to execute.
         Calling a function always pushes
         the return address onto the stack.


                                         back   next
Problems with the Stack

        The problem with this design shows up within the
         called function.
        Any variables defined within this function are also
         stored in space allocated on the stack.
        For example, if a string, such as the name of a file
         to open, needs to be defined in the function, that
         number of bytes will be allocated on the stack.
        The function can then use this memory, but it will
         automatically be unallocated after the function
         returns.
        But C does no bounds checking when data is
         stored in this area, and this opens a hole for an
         attacker to exploit.

                                                       back     next
The Culprits

        C library calls that copy data but do no bounds
         checking are the culprits (as well as the
         programmers who use these calls).
        The strcat(), strcpy(), sprintf(), vsprintf(), bcopy(),
         gets(), and scanf() calls can be exploited because
         these functions don’t check to see if the buffer,
         allocated on the stack, will be large enough for the
         data copied into the buffer.
        It is up to the programmer to either use a version
         that makes the check (such as strncpy() ) or to
         count the bytes of data before copying them onto
         the stack.



                                                         back      next
The Culprits


        Given that there is a list of
         commonly abused subroutine calls,
         you might think it reasonable that
         all uses of these calls would be
         checked, and that the problem
         would be fixed forever.
        Actually, it’s not quite as easy as
         that, and there are other ways of
         making similar mistakes
         – appending characters in a loop

                                            back   next
The Culprits

        In addition to subroutine calls, an attacker
         must also understand enough assembly in
         order to code the exploit itself.
        In a buffer overflow exploit, code gets written
         on the stack, beyond the return address and
         function call arguments, and the return
         address gets modified so that it will point to
         the beginning (approximately) of the code.
        Then, when the function call returns, the
         attacker’s code gets executed instead of
         normal program execution.



                                                   back    next
The Art


         Getting the return address to point
          to the right location is one part of
          the ―art‖ of buffer overflow exploits.
         The other part covers the code
          itself.
         Commonly, an offset argument lets
          the attacker try different locations
          merely by applying different values
          to adjust the position of the
          modified return address.
                                            back   next
The Results

        Among the information that is lost by the overflow
         is the ordered list of subroutines that had been
         called by the program up until the time when the
         attack occurred. In addition, the called arguments
         are also lost.
        The intruder can overflow the buffer with a
         carefully crafted exploit script (a program written
         for malicious use) and then tells the program to
         treat the buffer as instructions and execute them.
        The program does what the intruder wants, not
         what the programmer intended. In effect, the
         intruder becomes the programmer because his or
         her instructions are executed.


                                                       back    next
The Results

        On Unix systems, a short program (which
         can be copied outright from existing
         exploits) executes a local program, most
         commonly the Unix command interpreter
         /bin/sh.
        If the attacker already has local access,
         the result often is an interpreter run with
         superuser privileges.
        If the attacker is remote, the TCP
         connection used to initiate the attack
         becomes connected to the shell program
         and often has superuser access. From
         here, the attacker can add a root account
         with their chosen password.
                                               back    next
Buffer Overflow History

        The Morris Worm (November 1988) was based on
         a buffer overflow in in the Unix fingerd daemon
        Microsoft IIS 5.0
         – Recently had a buffer overflow with WebDAV
         – Code Red and variants were buffer overflows
        WinXP Media Player and WinAmp both had buffer
         overflows from long ID3 tags in MP3s in
         December
        OpenSSL had buffer overflows that were only
         patched last July (Modap, Scalper, Slapper
         worms)
        Of course, the ―King of buffer overflows‖ is most
         definitely Sendmail, which just had another one
         discovered and patched on March 29


                                                         back   next
Security Advisories

        Security advisories including malicious
         buffer overflow exploit information are
         posted by CERT at http://www.cert.org/
        Buffer overflows are typically easy to
         patch, so usually within minutes or hours,
         a solution is available
        System Administrators will monitor such
         sites carefully so as to keep systems and
         software patched and up to date
        Unfortunately there is still the time gap
         between exploit discovery/release and
         the patching of systems, so these
         vulnerabilities are still problematic
                                              back    next
Combating Buffer Overflows

        Secure programming
         – This is difficult to implement, as legacy
           software and hardware may not be able to use
           secure library functions
        Non-executable Runtime Stack
         – Implemented in OpenBSD 3.2
        Static Detection
         – Only some buffer overflows can be detected
           statically. So this can’t solve all potential
           problems
        Run-time Stack Inspection (StackGuard)
         – Can detect most common buffer overflows
         – Drawback is additional overhead, as well as
           the inability to detect heap-based overflows, or
           those related to function pointers        back   next
How StackGuard Works

                 Standard   StackGuard
               Stack Layout Stack Layout
      0xFFFF   Top of Stack Top of Stack

               Return       Return
      Stack    Address      Address
      Growth   Local        Canary Word
               Variables    Local
               …            Variables …
      0x0000   Buffer       Buffer

                                      back   next
How StackGuard Works

       Since most buffer overflows are caused by string
        manipulation, it is difficult to modify return
        addresses on the stack without modifying the
        ―canary word‖ as well
       This is because the stack counts from low to high
        for addressing buffers/strings
       The main problem however is a stray pointer.
        Function pointers especially can be overwritten to
        point to other malicious code
       Thus this method is effective for combating some
        buffer overflows, but cannot be used to eliminate
        them completely



                                                     back    next
Heap-based Buffer Overflows

        In addition to stack-based attacks, it is
         also possible to abuse the heap in a
         similar manner
        Famous example is Code Red worm
        Basically the difference is that an
         overflowed buffer in the heap is used to
         modify another data structure’s members
        Can also be used to modify function
         pointers in the heap, which are used in
         many Object Oriented programming
         languages to provide virtual function calls

                                               back    next
Heap-based Exploit Protection


        Luckily, these flaws are usually
         harder to exploit, due to potential
         varieties in memory layout after
         long run time of a program, but…
        Non-executable heaps are not as
         popular or widespread as non-
         executable stacks
        No simple solution to catch most of
         these types of exploits (like
         StackGuard’s canary word)
                                        back   next
Conclusion

        It is possible to avoid most buffer
         overflows through good
         programming practices
        Tools are available that can help
         detect potential buffer overflow
         vulnerabilities
        Security is a ―must-have‖ and not a
         feature for programs today, since
         viruses/worms can be so
         devastating in a short amount of
         time
                                        back   next
References

        ―Aleph One‖. Smashing the stack for fun and profit.
         Phrack, 7(49), November 1996.
        M. Conover and w00w00 Security Development.
         w00w00 on Heap Overflows.
         http://www.w00w00.org/files/articles/heaptut.txt,
         January 1999.
        C. Cowan, C. Pu, D. Maier, et al. Stackguard:
         Automatic adaptive detection and prevention of buffer-
         overflow attacks. In Proceedings of the 7th USENIX
         Security Symposium, pages 63—78, San Antonio, TX,
         January 1998.
        Rogers, Larry. Buffer Overflows – What Are They and
         What Can I Do About Them?.
         http://www.cert.org/homeusers/buffer_overflow.html.
        D. Wagner, J. Foster, E. Brewer, and A. Aiken. A first
         step towards automated detection of buffer overrun
         vulnerabilities. In Network and Distributed System
         Security Symposium, San Diego, CA, February 2000.
                                                          back    next

								
To top