Web Vulnerabilities Part 5: Buffer Overflow 11-22-2012, 11:30 PM
#1
Sometimes we can see executable programs being used as part of the application providing unique features. But even though the executables are being used as part of web applications, buffer overflow vulnerabilities still exist. Imagine that a web application is calling a system function to call an executable with the user inputted parameter. This doesn’t prevent the buffer overflows that could be present in executables from overflowing the program stack or heap structures.
An example of a C program that contains a buffer overflow vulnerability is as follows:
The program accepts an input argument, but doesn’t check for the length of the argument. When it accepts the input argument, that argument is sent to the copy function, which copies the argument into a local buffer with the strcpy function call. But there are only 20 reserved bytes in the local array, so if we copy an argument that is longer than 20 characters, a buffer overflow will occur. This will crash the program at least, but a specifically crafted input argument could execute arbitrary code on the target system.
Preventing
Avoid using library files included with the compiler
Library files are commonly included with a programming language. If a hacker finds a weakness with a particular library file, any application that includes that particular library file also has the weakness. So if a hacker wants to exploit a home-grown application, he will often start by trying to exploit known weaknesses in commonly used libraries.
Libraries are also inherently insecure. Although newer compilers are starting to include more securely-written library files, for the longest time libraries offered a quick-and-easy way to accomplish a task with little regard for secure coding. This was especially true of the C++ programming language. Programs coded in C++ that rely on the standard libraries are very susceptible to run-time errors, a dream come true for hackers looking for a buffer exploit.
Stack cookies
A stack cookie, or "canary," is essentially a randomized piece of data that an application can be made (using a compiler option)to write to the stack just before EIP. That means that if data overflows from its assigned buffer into EIP, it will overwrite the stack cookie too. Just as canaries where used in mines in the 19th century to indicate whether the air was healthy or toxic, the application uses the state of the stack cookie canary to check the health of the system. If the stack cookie has been changed then this indicates a buffer overflow, and the application is terminated.
Data Execution Protection
Hardware DEP, which is available with specific processors, basically marks certain areas of the stack as non-executable areas. That means that any shellcode places in the stack simply won't execute.
Address Space Layout Randomization (ASLR)
ASLR, a feature of many modern operating systems, randomizes the base address of executables, dlls and other items in a process's address space. These addresses change with each system boot, making it impossible to use JMP commands in system dlls, since their locations are no longer predictable.
Although these technologies can make exploiting a buffer overflow considerably harder, all three of them can be overcome in certain circumstances.
An example of a C program that contains a buffer overflow vulnerability is as follows:
Code:
void copy(char **argv) {
char array[20];
strcpy(array, argv[1]);
printf("%s\n", array);
}
main(int argc, char **argv) {
copy(argv);
}The program accepts an input argument, but doesn’t check for the length of the argument. When it accepts the input argument, that argument is sent to the copy function, which copies the argument into a local buffer with the strcpy function call. But there are only 20 reserved bytes in the local array, so if we copy an argument that is longer than 20 characters, a buffer overflow will occur. This will crash the program at least, but a specifically crafted input argument could execute arbitrary code on the target system.
Preventing
Avoid using library files included with the compiler
Library files are commonly included with a programming language. If a hacker finds a weakness with a particular library file, any application that includes that particular library file also has the weakness. So if a hacker wants to exploit a home-grown application, he will often start by trying to exploit known weaknesses in commonly used libraries.
Libraries are also inherently insecure. Although newer compilers are starting to include more securely-written library files, for the longest time libraries offered a quick-and-easy way to accomplish a task with little regard for secure coding. This was especially true of the C++ programming language. Programs coded in C++ that rely on the standard libraries are very susceptible to run-time errors, a dream come true for hackers looking for a buffer exploit.
Stack cookies
A stack cookie, or "canary," is essentially a randomized piece of data that an application can be made (using a compiler option)to write to the stack just before EIP. That means that if data overflows from its assigned buffer into EIP, it will overwrite the stack cookie too. Just as canaries where used in mines in the 19th century to indicate whether the air was healthy or toxic, the application uses the state of the stack cookie canary to check the health of the system. If the stack cookie has been changed then this indicates a buffer overflow, and the application is terminated.
Data Execution Protection
Hardware DEP, which is available with specific processors, basically marks certain areas of the stack as non-executable areas. That means that any shellcode places in the stack simply won't execute.
Address Space Layout Randomization (ASLR)
ASLR, a feature of many modern operating systems, randomizes the base address of executables, dlls and other items in a process's address space. These addresses change with each system boot, making it impossible to use JMP commands in system dlls, since their locations are no longer predictable.
Although these technologies can make exploiting a buffer overflow considerably harder, all three of them can be overcome in certain circumstances.
![[+]](https://sinister.ly/images/modern/collapse_collapsed.png)
