Buffer overflow holes in programing

A buffer overflow occurs when you write a string (usually a string of characters) into an array, and keep on writing past the end of the array, overwriting whatever happened to be after the array.

Security-problem buffer-overflows can arise in several situations:

• when reading input directly into a buffer;
• when copying input from a large buffer to a smaller one;
• when doing other processing of input into a string buffer.

Remember, it’s not a security hole if the input is already trusted — it’s just a potential annoyance.

This is particularly nasty in most Unix environments; if the array is a local variable in some function, it’s likely that the return address is somewhere after it on the stack. This seems to be the fashionable hole to exploit; thousands and thousands of holes of this nature have been found in the last couple of years.

Even buffers in other places can sometimes be overflowed to produce security holes — particularly if they’re near function pointers or credential information.

Things to look for:

• dangerous functions without any bounds-checking: strcpy, strlen, strcat, sprintf, gets;
• dangerous functions with bounds-checking: strncpy, snprintf — some of these will neglect to write a NULL at the end of a string, which can result in later copying of the result to include other data — possibly sensitive data — and possibly crashing the program; this problem does not exist with strncat, and I’m not clear on whether it exists in snprintf, but it definitely exists with strncpy;
• misuse of strncat, which can result in writing a null byte one past the end of the array;
• security-sensitive programs crashing — any crash comes from a pointer bug, and perhaps the majority of pointer bugs in production code are from buffer overflows.
• Try feeding security-sensitive programs big inputs — in environment variables (if environment variables are untrusted), in command-line parameters (if command-line parameters are untrusted), in untrusted files they read, on untrusted network connections. If they parse input into chunks, try making some of the chunks enormous. Watch for crashes. If you see crashes, see if the address at which the program crashed looks like a piece of your input.
• incorrect bounds-checking. If the bounds-checking is scattered through hundreds of lines of code, instead of being centralized in two or three places, there’s an extremely good chance that some of it is wrong.

A blanket solution is to compile all security-sensitive programs with bounds-checking enabled.

Related posts:

1. Finding security holes in programing
2. Resources scarcity in programing
3. PHP mbstring buffer overflow vulnerability
4. Avast! antivirus buffer overflow vulnerability
5. vulnerability stems from a buffer overflow condition in IE for an XML
6. Buffer overrun

Related posts brought to you by Yet Another Related Posts Plugin.