7

I have read 5 Papers/articles and 2 videos on Stack Buffer Overflows, and Heap overflows. I have written a program that was vulnerable overflowed and exploited that, ran a server on port 7777 that was vulnerable, overflowed and exploited that. But what I don't understand is how to find vulnerabilities in Windows (or other operating systems) or software. I was using gcc and gdb to do debugging to find everything I need to write the exploit. How do I find Stack Buffer Overflow vulnerabilities on other programs/software and how do I debug the vulnerable program or can I use gdb?

trincot
  • 317,000
  • 35
  • 244
  • 286
Noah_DuV
  • 73
  • 1
  • 5
  • gcc and gdb are also available for Windows. – Werner Henze Apr 24 '15 at 13:19
  • Can You tell me how You achieved the two exploits You are talking about? Especially the targeted os I would like to know. – icbytes Apr 24 '15 at 13:22
  • If what you're trying to do is legal then I would presume you can request and receive the source code of the software whose weaknesses you want to test. – David K Apr 24 '15 at 13:48
  • The first program that I overflow/exploited was a simple program that took input and saved it to a buffer with out checking the bounds. Using gcc and gdb to find how many bytes was needed to get to the frame pointer. That was done on windows 7 64bit. The second exploit was a remote exploit, I hosted a server on a laptop (OS is kali-linux), the server program allowed computer to connect to it and then could take input(command) and didn't check it's bounds. I attached gdb to the server, once the buffer was overflowed I used gdc and core dump to find where the stack pointer was- to icbytes – Noah_DuV Apr 24 '15 at 13:56

1 Answers1

11

There are two main approaches for finding stack buffer overflows:

Black box testing The key to testing an application for stack overflow vulnerabilities is supplying overly large input data as compared to what is expected. However, subjecting the application to arbitrarily large data is not sufficient. It becomes necessary to inspect the application’s execution flow and responses to ascertain whether an overflow has actually been triggered or not. Therefore, the steps required to locate and validate stack overflows would be to attach a debugger to the target application or process, generate malformed input for the application, subject the application to malformed input, and inspect responses in a debugger. The debugger allows the tester to view the execution flow and the state of the registers when the vulnerability gets triggered

Gray Box Testing Manually review the code (disassemble it). When reviewing code for stack overflows, it is advisable to search for calls to insecure library functions like gets(), strcpy(), strcat() etc which do not validate the length of source strings and blindly copy data into fixed size buffers. Apart from manually reviewing code for stack overflows, static code analysis tools can also be of great assistance. Although they tend to generate a lot of false positives and would barely be able to locate a small portion of defects, they certainly help in reducing the overhead associated with finding low hanging fruits, like strcpy() and sprintf() bugs. A variety of tools like RATS, Flawfinder and ITS4 are available for analyzing C-style languages.

The best tools for those testings are: OllyDbg and IDA Pro (for static and dynamic debugging).

Slava Bronfman
  • 160
  • 1
  • 6