Buffer-Overflow Attacks

					 Buffer overflow occurs when data written
  to a buffer corrupts data values in
  memory addresses adjacent to the
  allocated buffer
 Usually due to insufficient bounds
  checking
 Most common when copying strings of
  characters between buffers
   1988 – Morris Worm
    › Earliest Documented
    › Exploited ‘finger’ on Unix systems
   2001 – Code Red Worm
    › Exploited Internet Information Services 5.0
   2003 – SQL Slammer
    › Exploited Microsoft SQL Server 2000
   2003 – Xbox
    › Allowed for homebrew games to be run
     without hardware modifications
   The heap contains dynamically assigned variables
    such as linked lists and other data structures.
   Exploits can cause overwrites in existing data
    structures
   One method is to exploit dynamic memory allocation
    (malloc) to cause created pointers to overwrite
    function pointers
   This allows the attacker to have custom functions run
    instead of the ones originally programmed
   The iphone and ps3 were attacked with heap
    overflow attacks to allow third party software to run
#define BUFSIZE 16
#define OVERSIZE 8 /* overflow buf2 by OVERSIZE bytes */

int main()
{
          u_long diff;
          char *buf1 = (char *)malloc(BUFSIZE), *buf2 = (char *)malloc(BUFSIZE);

         diff = (u_long)buf2 - (u_long)buf1;
         printf("buf1 = %p, buf2 = %p, diff = 0x%x bytes\n", buf1, buf2, diff);

         memset(buf2, 'A', BUFSIZE-1), buf2[BUFSIZE-1] = '\0';

         printf("before overflow: buf2 = %s\n", buf2);
         memset(buf1, 'B', (u_int)(diff + OVERSIZE));
         printf("after overflow: buf2 = %s\n", buf2);

         return 0;
}
   Output
buf1 = 0x804e000, buf2 = 0x804eff0, diff = 0xff0
  bytes
before overflow: buf2 = AAAAAAAAAAAAAAA
after overflow: buf2 = BBBBBBBBAAAAAAA

This works because buf1 overruns its boundaries
   into buf2's heap space. But, because buf2's
   heap space is still valid (heap) memory, the
   program doesn't crash
   Since version 2.3.6 the GNU libc includes
    protections that can detect heap overflows after
    the fact, for example by checking pointer
    consistency when calling unlink.
    › Prevents older exploits but is not perfect
   Since Windows XP SP2, microsoft implemented
    protection against Heap Overflow
    › Such as safe unlinking
    › Data Execution Prevention (DEP) and Address space
      layout randomization(ASLR).
       Randomize allocations to prevent sequential variables from being
        near eachother in memory

   Dhard and other third Party Scanners
 Occurs when a program writes to a
  memory address on the program's call
  stack outside of the intended data
  structure.
 A program could write more data to a
  buffer located on the stack than there was
  actually allocated for that buffer.
 Results in corruption of adjacent data on
  the stack.
 Stack buffer overflow was used to hack the
  Nintendo wii to allow homebrew games via
  the twilight hack
  Simple example using strcpy:
#include <string.h>
void foo (char *bar)
{
   char c[12];
   strcpy(c, bar); // no bounds checking...
}
int main (int argc, char **argv)
{
   foo(argv[1]);
}
 If the input is more than 11 bytes then the
  local data stack, frame pointer, and
  return address will be overwritten.
 Using this it is possible to redirect the
  function to the attackers custom
  functions.
 If the program is running with elevated
  privileges this could allow the attacker to
  gain root access to the system
   Stack Canaries
    › A value set before the return pointer using a
      random number set at start
    › The value is checked before a routine uses the
      return pointer on the stack to ensure it was not
      overwritten.
    › This prevents attackers from executing custom
      code
    › Forces the attacker to gain control of the
      instruction pointer by some nontraditional means
      such as corrupting other important variables on
      the stack
   Non executable stack
    › Makes the stack memory unable to execute
      shell code that may be called
    › Prevents most traditional stack buffer
      overflows
    › Attacker can still call a routine in
      unprotected memory, such as the heap
In real-world exploits there are a variety of
challenges which need to be overcome for
exploits to operate reliably.
    - Null bytes in addresses.
    - Variability in the location of shellcode.
    - Differences between environments.
    - Various counter-measures in operation.
 A exploiting a NOP-sled is the oldest and
  most widely known technique.
 A NOP slide/sled is a sequence
  of NOP (no-operation) instructions meant
  to "slide" the CPU's instruction execution
  flow to its final, desired, destination.
 They are used to try and prevent the
  occurrence of exceptions and the
  resulting crash.
 Solves the problem of finding the exact
  address of the buffer by effectively
  increasing the size of the target area.
 Requires the attacker to guess where on
  the stack the NOP-sled is instead of the
  comparatively small shellcode.
 At the end of the attacker-supplied data,
  after the no-op instructions, an instruction to
  perform a relative jump to the top of the
  buffer where the shellcode is located.
 Still must rely on some amount of luck
  that they will guess offsets on the stack
  that are within the NOP-sled region.
 Incorrect guesses will usually result in the
  target program crashing.
 NOP-sled requires a much larger amount
  of memory in which to hold a NOP-sled
  large enough to be of any use. Which is
  a problem if the buffer is small.
 Allows for reliable exploitation of stack
  buffer overflows without the need for
  extra room for a NOP-sled and without
  having to guess stack offsets.
 The strategy is to overwrite the return
  pointer with something that will cause
  the program to jump to a known pointer
  stored within a register which points to
  the controlled buffer and thus the
  shellcode.
  A program may not intentionally contain
  instructions to jump to a particular
  register. Making it so this type of attack
  isn’t always possible.
 Can be worked around if you can find
  an unintentional instance of a suitable
  opcode at a fixed location somewhere
  in program memory.
   Commonly used by internet worms
    because when the technique is possible
    it allows for automation of an attack with
    a virtual guarantee of success.