Dr. Dobb's Journal - October 2008 - (Page 25)

D10fish_p3as 8/14/08 12:46 PM Page 25 push sp ; push the SOMETYPE local variable push ap ; push the stream pointer (comes from 1st argument) call LoadTypeFromStream ret attackers are simply attempting to gain access to more information than they should normally see. In other cases, attackers are more concerned with storing new information in the database that will then be (a) void LoadTypeFromStream (unsigned char* stream, SOMETYPE* typtr) { int len; // Get the size of our type's serialized form memcpy(&len, stream, sizeof(int)); // De-serialize the type memcpy(typtr, stream + sizeof(int), len); } (b) void foo(unsigned char* stream) { SOMETYPE ty; LoadTypeFromStream(stream, &ty); } (c) void LoadTypeFromStream (unsigned char* stream, SOMETYPE* typtr) { int len; // Get the size of our type's serialized form memcpy(&len, stream, sizeof(int)); // GUARD if( len sizeof(SOMETYPE) ) throw TaintedDataException(); // De-serialize the type memcpy(typtr, stream + sizeof(int), len); } On calling foo(), the caller pushes the stream address onto the stack, along with the return address (pushed as an implicit side effect of using the call directive, or whatever platform equivalent is made available), so that the stack contents have the 128 bytes that are reserved for our type abutted directly against the return address back to the caller of foo(); see Figure 1. Now LoadTypeFromStream executes and writes 256 bytes into the address provided; that is, the value of the stack pointer (sp) before we called the function. This effectively overwrites the 128 bytes that are supposed to be used (at address 0x1000 in our example), plus the ensuing 128 bytes, including the incoming argument pointer, the return address, and whatever other information is stored in the next 128 bytes of the stack. So how do attackers exploit this vulnerability? Well, it’s not simple, and requires a tremendous amount of trial and error. In essence, attackers arrange the payload of the attack so that the overwritten return address transfers control to the attacker’s payload rather than to the expected calling function. The attacker therefore needs to know exactly what data structure is being exploited, how big it is on whatever version of the operating system or application that is being attacked, what surrounds it (so that the bogus return address can be placed correctly), and how to meaningfully insert enough information so that the return address plus the rest of the payload can do something harmful. Not easy things to do, but as many different attacks have shown, some people have way too much time on their hands! How should you defend against this type of attack? Is it one attack, or several? Does the code being written really have to be as dumb as that shown here? And don’t modern compilers do weird things to stack frame layout to get around this problem? In summary, obfuscation is no defense. We all realize that the easier the programmer makes the attack, the surer that the attack will come. Yet, even complex code that isn’t suitably defensive can (and will) be attacked sooner or later. This attack vector, which leverages both tainted data flow and a very basic buffer overflow vulnerability, has been the subject of continuous and heated research for years now, but still yields a significant number of exploits every year. Defense against this flaw is as trivial as the attack is complex— guard your data assumptions. The addition of one simple line of code to Example 1(a) makes it solid; see Example 1(c). Obviously, as the stream interaction becomes more complex so does the guarding requirement, but at its most basic, code injection qualifies as an “unforgivable” sin in coding, as the known defenses are so prevalent and so simple. Example 1: Injections attacks. SQL Injection There are also several different types of SQL injection that can cause significant problems for database-centric applications. In some cases, October 2008 l www.ddj.com l Dr. Dobb’s Journal 25 http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - October 2008

Dr. Dobb's Journal - October 2008 Contents Friday Night Fish Fry Alia Vox Developer Diaries Developer’s Notebook Is Your Next Language COBOL? Conversations Safe Coding Practices Code Signing in Adobe AIR OpenID Single Sign-On The Book Cipher Algorithm Indexing and Searching Image files Extending Continuous Integration Into ALM The Agile Edge Effective Concurrency Swaine’s Flames

Dr. Dobb's Journal - October 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.