Information Security & US & Life & Love & Fashion & Hacking & Passion

• White Papers
  • Smashing the stack for fun and profit or Hangul Translation Version by jykim@hackerslab.com
  • How to write buffer overflows or <>here
    
  • Advanced buffer overflow exploit or here
    
  • Buffer overflow exploit in the alpha linux or here
    
  • Writing buffer overflow exploits - a tutorial for beginners or here
    
  • Buffer overwrites
    
  • w00w00 on Heap Overflows or here
    
  • How 'buffer overflow' attacks
    
  • WindowNT Buffer Overflow's From Start to Finish" or here
    
  • m68k buffer overflows or here
    
  • Win32 Buffer Overflows
    
  • Stack Smashing Vulnerabilities in the UNIX Operationg System
  • djgpp Inline Assembly Guide
    
  • Startup state of Linux/i386 ELF binary
    
  • Self modifying code under Linux
    
  • Using the framebuffer device under Linux
    
  • Using the audio device under Linux
    
  • Using the raw keyboard mode under Linux
    
  • Using mode X via direct VGA access under Linux
    
  • The Art of Assembly Language Programming or here
    
  • Frame Pointer Overwrites - One-byte Buffer Overflow
• Sources
  • Shellcode - aix | bsdi | dg-ux | freebsd | hp-ux | linux-sparc | linux-x86 | netbsd | openbsd | openserver | ppc-bsd | ppc-linux | solaris-sparc | solaris-x86 | unixware | win32
• Tools
  • Shellcode Generator for linux-x86
  • Finding the Buffer Overflow Vulnerabilities

Buffer overflows are one of the more complex injection attacks, as they take advantage of developers misusing memory. Like command injection, a successful buffer overflow attack gives the attacker complete control of the remote machine.

Some programming languages, such as C and C++, place memory management responsibilities on the developer. If the developer is not careful, user input could write to memory that was not intended to be written to. One such memory location is called the return address of a stack. The return address holds the memory address of the next machine instruction block to execute. If an application is vulnerable to buffer overflows, an attacker could send a very long string to the web application—longer than the developer expected. The string could potentially overwrite the return address, telling the web application what machine instructions it should execute next. The injection aspect of buffer overflows is that the attacker injects machine instructions (called shell code) into some user input. The attacker somewhat needs to know where the shell code will end up in the memory of the computer running the web application. Then the attacker overwrites the return address to point to the memory location of the shell code.

Exploiting buffer overflows are nontrivial, but finding them is not as difficult, and finding buffer overflows on a local machine is easy. You need only send very long strings in all user inputs. We suggest inputting predictable strings, such as 10,000 capital As, into each input. If the program crashes, it is most likely due to a buffer overflow. Repeat the crash while running the application in a debugger. When the program crashes, investigate the program registers. If you see 41414141 (41 is the ASCII representation of a capital A) in the SP register, you have found a buffer overflow.

Finding buffer overflows on remote machines, such as a web application, is a lot more difficult, because attackers cannot view the contents of the web application’s registers, and it may even be difficult to recognize that the web application has even crashed. The trick to finding buffer overflows on web applications is to do the following:

1. Identify what publicly available libraries or code the web application is running.

2. Download that code.

3. Test that code on your local machine to find a buffer overflow.

4. Develop exploit code that works on your local machine.

5. Attempt to execute the exploit code on the web application.