How to prevent arbitrary code execution vulnerability in our programs?

You always read in changelogs when your system or browser or any program updates that they fi开发者_高级运维xed a bug that made possible that an attacker can execute any code in your computer with a forged website, or attacking your computer with carefully forged packets, etc...

Because you read it so often that means any program can have similar vulnerabilites... What causes this? how to design our programs to prevent similar issues?

One example of how a bug can create an opportunity for exploit:

Let's say you have a subroutine in a program that modifies data in an array of characters. Let's say it also contains a bug that when the array is a particular size or the array contains particular characters, the subroutine inadvertantly writes past the end of the array of characters.

This by itself doesn't seem like much of an opportunity, but depending on how execution reaches the subroutine and other artifacts of how it is implemented and compiled, it could be used as a springboard to executing arbitrary code.

In traditional programming (C, C++), character arrays (buffers) are often stored on the program stack. The stack is very fast and easy memory allocation for smallish temporary data.

Another thing that is stored on the stack is the function call return address - what code address to return to when this function exits.

Now you have all the pieces needed to create disaster: If you can pass just the right data to this subroutine to make it overwrite the stack, and overwrite it enough to overwrite the function return address that is also on the stack not far from the data buffer, then you have the potential to alter where program execution will return to when the function exits. Instead of returning to the caller, it could be made to "return" (jump, really) to Halt() or Format() or PhoneHome(). Any function in any library or DLL referenced by the current process is accessible at this point.

This is just one example of an arbitrary execution exploit. There are dozens of such patterns.

The easiest way to thwart this particular exploit is to ensure that your code respects the bounds of your data buffers. For most compilers, this means turning on range checking or similar runtime checks. The compiler will emit code to validate that an array index value is in range before accessing the memory location in the array.

The first and most important rule is "trust no one."

• Don't trust the user's description of their data (record counts, array lengths, etc).
• Don't regurgitate anything the client gives you without having carefully examined it first and rendered it harmless (escaping unprintable characters, validating conformance with structure boundaries and types, etc).
• Always assume that when you are being supplied with information, it will be corrupted. Strings will not be terminated. Arrays will be mis-sized. Structures will be missing pieces. Packets will be oversized or incomplete.

The key is "defensive programming". Always examine the most malicious, malformed way that your functions could receive their parameters and then plan around it. Never assume that just because you wrote the code on the other end, you can trust its description of what it's handing you. This goes doubly so for any code which is in the hands of an end-user. The client is in the hands of the enemy.

Adopt this mindset thoroughly and you'll be better prepared for withstanding attacks. But you'll still make mistakes -- everyone does -- and need to respond to them and have an update process in place for your customers.

There is a book The Shellcoder's Handbook: Discovering and Exploiting Security Holes, ISBN 978-0470080238, that goes into great detail into the various types of exploitations (stack overflow, heap overflow, sql injection, etc).

There are good "google" sources for this problem, but in short, you need to make all your calls (function calls, method calls, etc) safe. Safe means they truncate incoming data to its right size, do not 'eval' it, and so on.

The number of possible attacks is very large. You may want to read Bugtraq to keep on top of things.

Hope this helps!