Buffer Overflow Attacks

In an era where everything is digitized, there is always some scope for a loophole or vulnerability. This loophole forms the crux where hackers squeeze in their mischievous codes and hence flourish their business. You may expect a businessman to cut loose his profit, but you can never bargain on an attacker to miss vulnerability in a code. One such common and phenomenal technique employed by this vigilant group is Buffer Overflow.

What is Buffer Overflow?

Dominating network penetration areas, buffer overflow has been a common security vulnerability in the past decade. Subverting a privileged program’s function and taking control of the same is the invading strategy behind this technique.

In a broad spectrum, Buffer Overrun or Buffer Overflow is a flaw that occurs when a program writes more information into the buffer block than it is permitted to hold. Subsequently, the buffer’s boundaries are overrun, overwriting the adjacent memory blocks with corrupt values due to inadequate bounds checking. As a consequence, it allows an anonymous Internet user to execute his own code instead of the program code, thus partially or completely hijacking control of the host machine.

Buffer Overflow Attack- The Technical Know-How

Buffer Overflow attack emanates from the susceptibility provided by poor programming practices coupled with the C language framework.

The vulnerabilities that string along with this phenomenon particularly entail code that:

• Depends on external input to control its behavior.

• Relies upon data properties that are outside the immediate scope of the code.

• Is too complex for the programmer is to predict its actual behavior.

On the basis of buffer location, they are generally divided into two broad categories: Heap Based Overflow and Stack Based Overflow. Although buffers might be present in other locations of process memory, such flaws are almost rare.

Stack Based Overflow

A stack is a memory structure branched into equal sized segments and used to nest data. This data generally stores function’s return addresses, local variables and parameters that form a part of the program code. It operates in accordance with the LIFO model; wherein the data value ‘pushed’ last is the one ‘popped’ first.

In stack based overflow, the buffer is located on the stack. The following code demonstrates the phenomenon-

In the example above, the bad function receives argv[1] as a command-line argument. This is transferred to the dest_buffer, allocated 32 bytes of memory size. Any command-line argument exceeding the size of 31 bytes causes an undefined behavior- string length in tandem with null terminator exceeds the buffer length. Practically, the further action is dependent on the command-line argument contents and the compiler used. Needless to say, a 40 ‘A’ string will definitely lead to system crash!

Now the attacker must code in a way that a return address is specified pointing to his malicious commands. Although the program makes a run at recovering, post stack overflow, the malicious command is what the return address points to. Thus, he can execute his nasty code flawlessly. Of course, knowing where to reside the malicious command is a must, for which padding is done. Once the programmer is successful in running his codes, the command prompt is opened in the background with the same permissions as promised to the application, which often furnishes a full system control to the attacker.

Heap Based Overflow

Heap is yet another memory structure that stores data which is too large to fit on a stack. Now and then it is used by programmers for storing ‘dynamic’ memory whose size is not known till the compile time.

The buffer in heap based overflow is located on a heap. The following example makes the process self-explanatory-

The idea behind heap overflow exploit is in the same lines as stack based- identify the ‘weak points’ that is, the data post overflow that can be exploited to take the program execution control in own hands. Exploitation begins with corrupting the program data contained in heap memory, in ways to cause overwriting of internal structures. Overwritten dynamic memory linkages like malloc data ensures ease of pointer exchange, thus allowing the attacker to point to a different ‘malicious’ code. However, the difficulty and complexity involved in heap overflow makes it a rarely used technique.

Protective Countermeasures

Numerous techniques have been identified to detect and prevent buffer overflows, with certain tradeoffs. Some of the choices and implementations available are discussed below:

• Use of safe libraries – Buffer overflows can be prevented by maintaining high degree of code correctness and avoiding the usage of standard library functions that are not bounds checked, such as scanf, gets and strcpy.

• Choice of programming language – It is recommended that we prefer C++ over C for writing program codes since C language doesn’t provide any check on the data being inserted into a buffer while C++ has safer ways of buffering data.

• Deep packet inspection – This method uses the signatures and heuristics of a known attack at the network parameter, and prevents buffer overflow by blocking them.

• Executable space problem – This approach to buffer overflow protection refrains the execution of code on the stack or heap. An attacker may use buffer overflows to write arbitrary program code into the memory, but with executable protection of space, any attempt to execute it will cause an exception.

Popular Attacks

References

• https://en.wikipedia.org/wiki/Buffer_overflow

• https://www.owasp.org/index.php/Buffer_Overflow

• http://searchsecurity.techtarget.com/news/1048483/Buffer-overflow-attacks-How-do-they-work

• https://www.youtube.com/watch?v=iZTilLGAcFQ