Sunday, February 11, 2007

BUFFER OVERFLOW EXPLOITS

A large number of exploits have been due to sloppy software development. Exceeding array bounds is referred to in security circles as "buffer overflow." These  are by far the most common security problems in software.

What's the computer vulnerability of the decade?  It's not the Y2K bug, according to computer science and security analysts, but a security weakness known as the buffer overflow.

So guys want to know about BUFFER OVERFLOW....its not wikipedia so i would like to suggest some steps which anybody can do to understand it in a savvy manner. Here I described an exploit named "Stack Smashing Exploit" for understand buffer overflow.

Buffer overflow is a common programming error.  There is not a single OS that is free from this error.  Buffer overflows have been causing serious security problems for decades. In the most famous example, the Internet worm of 1988 used a buffer overflow in fingerd.  The problem occurred several times so far in 2000. What is surprising is that a number of security oriented software such as SSH and Kerberos  also have these errors.

The Buffer Overflow Error

The essence of this problem can be explained by the following.  The line strcpy(p, q) is a common piece of code in most systems  programs.  An example of this is: char env[32]; strcpy(env, getenv("TERM")); The strcpy(p, q) is proper only when

  1. p is pointing to a char array of size m,
  2. q is pointing to a char array of size n,
  3. m >= n,
  4. q[i] == '' for some i where 0 <= i <= n-1

Unfortunately, only a few programs verify that all the above hold prior to invoking strcpy(p, q).  A buffer overflow occurs when an object of size m + d is placed into a container of size m. This can happen in many situations when the programmer does not take proper care to bounds check what their functions do and what they are placing into variables inside their programs.   If n  > m in the strcpy(p, q) of above an area of memory beyond &p[m] gets overwritten.

A few other examples of such buffer overflows:

#char input[20]; gets(input);


Buffer Overflow Exploits

An attacker exploits this programming mistake.  He injects cleverly constructed data / executable-code into the area beyond the declared sizes.  If the "buffer" is a local C variable, the overflow can be used to force the function to run code of an attackers' choosing. This specific variation is often called a ``stack smashing'' attack. A buffer in the heap isn't much better.  Attackers have been able to use such overflows to control other variables in the program.

NOTE: THESE STEPS I FOUND SOMEWHERE ARE VERY USEFUL IF FOLLOWED CAN EASILY MAKE U UNDERSTAND ALL ABOUT BUFFER OVERFLOW.

Lab Experiment

Objective: Understand the stack smashing buffer exploit thoroughly.

  1. Download the article by Aleph One.  You will be extracting the source code of exploit3.c and exploit4.c files from it.
  2. Study the code of exploit3.c and exploit4.c that you extracted. 
  3. Improve the code so that there are no warning messages from gcc even after using the flags as in
        gcc -ansi -pedantic -Wall.
  4. Reduce the size of their compiled binaries by at least 5% as seen by the size command when exactly the same flags are used in the compilation.  Make sure no functionality is lost.
  5. Login as any non-root user.  Verify that the exploit still works on the vulnerable program.
  6. Turn in a lab report (of say 2-4 pages) with answers to the questions below, and thoroughly describing your changes, and how you verified that there was no loss of functionality.  Attach hard copies of properly indented versions of your exploit[34].c files.  Use indent -kr.
  7. Answer the question: What is the "environment"?
  8. Answer the question: Why does exploit3.c run system("/bin/bash") at the end of main()?


Even the security is not secure, loop holes are not the defects but the key to preci

posted by Anuj Agarwal @ 12:40 PM Comments: 0