In programming jargon, a buffer is an area in memory which is usually used to temporarily store data. Buffers are usually local variables of a function which are stored in the runtime stack of a program in a way that would make manipulation of such values easier. Other data like address of the next program instruction which will be executed when a function returns from execution are also stored in the stack. Since a stack is a contiguous area of memory which usually grows towards lower memory addresses, the possibility of buffer overflows, which is overwriting other memory area beyond the size of the buffer being write onto, is high especially for programs which perform poor bound checking. In most cases, non-deliberate buffer overflows lead to the corruption of important program data making the behaviour of the program unpredictable or the program will simply crash because of segmentation fault. On the other hand, a typical, deliberate buffer overflow is crafted in such a way that the program control flow is altered which enable an attacker to make the program point to a memory address containing malicious code and gets it executed[1].
Although the issue of buffer overflows existed as early as the 1980s, it gained popularity as an immediate security threat only after when the wrath of the infamous Morris Worm [1] took in. As the first well-known computer worm to have made use of the concept behind buffer overflow, Morris Worm set the sail for an effort among computer professionals to develop tools and techniques that would mitigate and prevent further exploitations of such a common vulnerability.
Several efforts had been made that aim to prevent, and stop exploitation of such vulnerabilities. Each of them was proven to be successful in their own rights [1, 4]. But as time goes by, these preventive mechanisms were seen to have loop holes also, which defeated the security they provide [4, 5].
Although new programming technologies i.e. type safe languages, engrained bound checking in languages like Java, decreased if not completely eradicated such a threat, the existence of legacy systems and the continued support to it, keep the risks pose by such attacks at the highest level. I believe, in fairness to a language like C, that the problem is not really in the language per se; rather it is on the individuals who write programs using it. In general, without proper awareness and the surge of different factors during software development, it becomes harder for software developers to examine each of the different aspects of a computer program. Unfortunately, program security is one such aspect which is simply forgotten during development. Although some studies are being conducted on this particular area, for example [3], it still lacks major breakthroughs that would enable the adaptation of a standard security framework for building secured software applications.
Because it is in the nature of computer hackers to unravel vulnerabilities in existing systems widely used by the computing community and exploit them “for fun and profit” [2], it is a constant struggle for security professionals to cope and move ahead of them.
References:
[1] Crispin Cowan, Perry Wagle, Calton Pu, Steve Beattie, and Jonathan Walpole. Buffer Overflows: Attacks and Defences of the Vulnerability of the Decade
[2] “Aleph One”. Smashing The Stack For Fun And Profit. Phrack, 7(49), November 1996
[3] Gary McGraw, Brian Chess, Sammy Migues. Software [In]security: The Building Security In Maturity Model (BSIMM). InformIT, at [http://www.informit.com/articles/article.aspx?p=1332285]. March 16, 2009
[4] Alexander Sotirov, Mark Dowd. Bypassing Browser Memory Protection – Setting back browser security by 10 years.
[5] Bulba and Kil3r. Bypassing Stackguard and Stackshield. Phrack, at [http://www.phrack.org/issues.html?issue=56&id=5], May, 2000
No comments:
Post a Comment