AppSec Blog

Top 25 Series - Rank 3 - Classic Buffer Overflow

Classic buffer overflow (CWE-120) is a huge problem in programming, we have all seen the damage that can be done by buffer overflow. There were numerous worms that leveraged this vulnerability in the early 2000's. Starting from the Morris worm early on, extending to the Code Red and SQL Slammer, they are all proof that buffer overflow is serious.

Classic Buffer Overflow is caused by a simple principle - if you fill a cup with too much water, it will overflow. When a programmer copy an object from one place to another and the destination container isn't big (or long) enough to hold the object, overflow will happen. Computer operations happens in memory, when the overflows happen, the overflowed content leaked into other parts of the memory. Coincidentally, the CPU takes instructions on what to execute from the memory as well, when there are overflow content in the memory space and CPU happen to stumble across the data and start executing the data from the leaked content. The CPU is running something that isn't intended. When an attacker can control the overflow content carefully and therefore control the CPU, the attacker effectively owns the machine.

A very common cause of buffer overflow is developer's lack of knowledge or careless mistake leading to the use of unsafe functions that does not take length into account when copying data, like the C function - strcpy. Developer education is really important. Internal mandate to get rid of dangerous C function is also important.

For environment where there is a language choice, moving to newer generation of Enterprise languages may be beneficial for avoiding buffer overflow. Java, C#, PHP, Python, Ruby are all designed to be resistant to buffer overflow.

Since buffer overflow is known to be a big problem, OS vendor, such as Microsoft have implemented OS level protections such as ASLR and stack execution prevention to avoid buffer overflow and these mitigation are reasonably effectively. More info on buffer overflow prevention here.

Overall, buffer overflow remains a problem today, developers need to be vigilant about avoiding buffer overflow and incorporate buffer overflow testing into the normal testing cycle. Even with a buffer overflow resistant platform, you really can't be sure of whether the ancient systems your application relies on is free of buffer overflow.


Posted March 4, 2010 at 8:19 PM | Permalink | Reply


DEP and ASLR are fast becoming marginalised as more and more methods are found to bypass these protections, such as the JIT Spray attack or the return-to-libc attack. Buffer overflows remain as dangerous as ever.

Posted April 17, 2010 at 1:56 PM | Permalink | Reply


Wow nicely explained, understand it now, cheers dude!

Post a Comment - Cancel Reply


* Indicates a required field.