Chapter 8: Buffer Overflows and Stack and Heap Manipulation

Overview

Buffer overflows (also referred to as buffer overruns) are a specific class of array and numeric bounds errors. They are one of the longest-running, costliest security vulnerabilities known to affect computer software. Understanding the core concepts behind buffer overflows can be fun and rewarding .

What is a buffer overflow, exactly? In simple terms, most buffer overflows take place when the input is larger than the space allocated for it, but it is written there anyhow and memory is overwritten outside the allocated location. When the data is written, it can overwrite other data in memory. In some cases, overflows result from incorrect handling of mathematical operations or attempts to use or free memory after the memory has already been unallocated . At first (casual) glance, overflowing the buffer can seem like a relatively harmless bug. However, overflows are almost always harmful . Buffer overflows typically result in enabling attackers to run whatever code they want to take control of the target computer.

Note  

Programming languages that allow for direct memory access (such as assembly, C, or C++) and those that do not provide bounds checking on buffers and numeric operations are particularly vulnerable to overflow attacks. Even languages such as Java (Java Native Interface) and C# (which contains unsafe code blocks and unmanaged application programming interface calls) include provisions for running external components that can be vulnerable to overflows. For some languages, risk of an overflow is reduced considerably by remaining within the language because the language helps perform memory validation on behalf of the programmer. But using safer languages should not substitute for the good programming practice of validating untrusted input. (Consider, for example, an overrun in the Netscape 4 Java Runtime engine. For more information, see http://secunia.com/advisories/7605/ . )

Buffer overruns have been around for a long time. In November 1988, Robert Morris launched a computer program that used known buffer overruns in UNIX services to locate and infect other computers. This became known as the Morris Worm. The Morris Worm attracted attention to security problems such as buffer overruns, so the problems have gone away, right? Wrong.

In January 2003, what began with sending a single little User Datagram Protocol (UDP) network packet reached epic proportions within minutes. Planes were grounded. People in some areas picked up their phones to no dial tone. ATMs stopped working. Networks across the globe and even portions of the Internet shut down. The president of the United States was notified. This wasn t a joke: it was called SQL Slammer and Sapphire. Then the costly mess had to be cleaned up, and questions surfaced. What had happened ? Microsoft SQL Server contained a buffer overflow security vulnerability that was remotely exploitable ”and someone actually exploited it. For all of the damage SQL Slammer actually caused, its primary action was to infect a vulnerable machine and then turn around and randomly try to infect other IP addresses. Just imagine what would have happened if the intentions of the worm s author were more sinister.

More Info  

For more information about how this particular overflow works, see h ttp://www.blackhat.com/presentations/bh-usa-02/bh-us-02-litchfield-oracle.pdf .

Consider another buffer overrun, this time in a Web server. According to Microsoft Security Bulletin MS01-033 ( http://www.microsoft.com/technet/security/bulletin/MS01-033.mspx ), idq.dll contains an unchecked buffer in a section of code that handles input URLs. An attacker who could establish a web session with a server on which idq.dll is installed could conduct a buffer overrun attack and execute code on the web server. Idq.dll runs in the System context, so exploiting the vulnerability would give the attacker complete control of the server and allow him to take any desired action on it. Sure enough, this overrun was exploited. Much like SQL Slammer, what was to be dubbed Code Red used the overflow to spread from machine to machine. Unlike SQL Slammer, however, Code Red also defaced the main Web site page and tried to execute a distributed denial of service attack on the http://www.whitehouse.gov domain (see http://www.eeye.com/html/Research/Advisories/AL20010717.html ).

The attackers didn t stop at spreading the worm and defacing Web sites. Another variant appeared, called Code Red II, which also opened up a number of additional security holes on systems, allowing others to run code with SYSTEM (equivalent to root) privileges even if the original overflow was patched (see http://www.eeye.com/html/Research/Advisories/AL20010804.html ). Code Red II was so successful at opening up a machine to further attacks that other worms such as Nimda later used the vulnerabilities opened up by Code Red II to spread (see http://www.microsoft.com/technet/security/alerts/info/nimda.mspx ).

Overrun vulnerabilities are not limited to network attacks or to particular platforms, devices, or vendors . Consider, for instance, a bug in both MacOS and Microsoft Windows iTunes clients that allows maliciously crafted URLs in playlist files to run code of an attacker s choice on the victim s machine when the playlist is processed ( http://www.kb.cert.org/vuls/id/377368 ) . Another example is a bug that occurs when specifying a filename longer than 98 characters in the tbtftp utility provided in Affix, a Bluetooth protocol stack written for Linux ( http://www.digitalmunition.com/DMA[2005-0712a].txt ). In mid-2005, an overrun was reported in ZLIB, a compression library broadly used in the computer industry. The ZLIB compression library is used for compressing many kinds of data and is popular on many platforms and in many applications because it is royalty-free and fairly feature-rich. In this particular case, an attacker could specify the compressed data, and on decompression the ZLIB routine would write data out of bounds ( http://www.kb.cert.org/vuls/id/680620 ). Buffers overruns regularly make headlines because they are serious issues that affect all computer users and software developers.

Because overruns are such effective tools in an attacker s arsenal, it is interesting delving into how to find them. Finding buffer overflows isn t just about inserting long strings in places and looking for crashes. This chapter details different types of overflows and how they work, shows some places to look for overflows, digs in for deep coverage of how to find overflows, covers determining overflow exploitability, and finishes off by discussing a few special topics. The testing approach details both structural (white box) and functional (black box) testing techniques and provides optional walkthroughs for those who are interested in expanding their knowledge even more.

Warning  

Attackers are clever and will likely try actions the tester didn t think were important to test “so thoroughness in testing is a good thing. New tools and techniques are continuing to emerge that will change what attackers have available to them long after the press used to print this page grows cold. The cost of shipping these bugs is often more than the cost of doing a decent job of finding and fixing them in the first place. It pays to budget accordingly and be resourceful in tackling overflows.

Before this chapter digs in and gets specific, take a minute to brainstorm about what your features do. Consider what sorts of places attackers can specify the data. What would be the most valuable prize? If the application takes data files from untrusted places and parses them, the data files would be great places to test for overruns. For network applications, look at what the target application receives over the wire as a big source of potential overruns. Another area for overruns is public (or private) application programming interfaces (APIs) that can be reused. A lot of the security work done with a given parameter on each API might depend on the API s design ”APIs designed to take unsigned buffer lengths are much clearer for the caller to use and hence less prone to buffer overflows. Some system data should not be trusted, such as Clipboard data that could come, say, through the Web browser from a malicious Web server using the scriptable Clipboard commands. Any code that runs with high privileges or has access to important information would be a good target because using the overflow would enable attackers to run commands using those high privileges or obtain the details of the sensitive information. Some examples of good targets might include authentication code, code that protects private cryptography keys, and other sensitive operations. Fasten your seatbelt and begin to think more about how attackers can maliciously shove data into the software to unleash its full potential.



Hunting Security Bugs
Hunting Security Bugs
ISBN: 073562187X
EAN: 2147483647
Year: 2004
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net