Testing for Overruns: Where to Look for Cases

In the grand scheme of things, there are a ton of test cases out there. Where do you get the biggest impact for your testing effort? You really want to find as many overflows as you can, but it is important to look for issues in some places more than in others. If attackers want an overflow to pay off, they need to somehow get the payload in the right place in the system. If the attacker has to convince the victim to type in the payload, the exploit probably won t work well for them ”they might as well settle for asking the victim to run an executable.

So where should you look first? Prioritizing testing is one area where doing a good job of threat modeling can really pay off. The threat models and data flow diagrams can help you discern which areas of the functionality have the most exposure so you can better plan your testing. Two key areas to focus on are the entry points and trust boundaries. Let s take a look at several places to look for data and overruns, including these:

  • On the network

  • In documents and files

  • In information shared between users with higher and lower privileges

  • In programmable interfaces

Caution  

Be wary of misevaluating whether an attack vector is feasible . Sometimes protected channels don t really protect against attacks. For example, many Secure Sockets Layer (SSL) servers will grant a protected channel to whomever asks for one so in this case just because the exploit would have to happen over SSL doesn t really protect the server against attack.

Network

The network is a given and has been the source of a number of attacks such as Code Red and SQL Slammer. Even so, sometimes network traffic might not be the best first place to look. Consider, for example, how bad it is if you already need a secure channel open and to be authenticated as an administrator before you can leverage an overflow that owns the server. It s no big deal ”in this case, you already can do whatever you want as the administrator. The focus should be on network traffic that is the most reachable for legitimate attack scenarios. This would include trying to elevate privileges or hijack other user accounts, anonymous requests , server responses, and Web-based attacks where an attacker might fool the administrator into sending malicious data over the network without realizing it.

One area to pay particular attention to is callbacks. The client calls the server and the server then calls the client back with information, and often the client simply accepts the data. This is particularly dangerous over the firewall because often the firewall lets an attacker right in when the attacker gives a network- borne response to a request from a target client inside the firewall.

Documents and Files

When users double-click a file in an e-mail message or open a file in an editor, can they trust that the file s contents won t harm their computer? Buffer overflows when parsing files are fairly common. Some data files are more important to scour than others.

Information Shared Between Users with Higher and Lower Privileges

One particularly attractive place to look for overflows is when information is shared among users who have different privileges. If an attacker can cause a log event to take place that overflows when the administrator uses administration tools, the overflow pays a huge dividend. If you know of an overflow in a network diagnostic tool the administrator uses, you can play with the network a bit to bait the trap, and then unplug your neighbor s network tap and wait for the administrator to start the tool. (Be careful ”administrators know a few tricks, too.) Some tools used by network administrators, such as NetMon, are not network administrator “ friendly and will even announce their presence on the network so attackers know exactly when to nail them.

As an attacker, you want to do cool and interesting things with the overflow, right? If you findan overflow in code running with guest permissions, it is much less interesting than is a system-level thread with much broader permissions. Using this argument to not fix an overflow often can prove deadly . Why? If you start running code in a thread with reduced privileges, you might be able to call functions like RevertToSelf or ImpersonateLoggedOnUser to elevate privileges in some cases where the thread is impersonating a particular low-privileged user. You might be able to manipulate another thread with higher privileges in the same process somehow (there are a lot of ways to accomplish this, from shatter attacks to named object hijacking to writing to shared memory or the other thread s stack). The general rule of thumb is to consider the sum total of all privileges the process is allowed at all times as the privileges accessible to attackers when they overflow any part of that process. For example, if a remote procedure call (RPC) server calls the RpcImpersonateClient function with 50 client users, an overflow on the server could potentially run arbitrary code over time as all 50 users as well as the security context of the main process.

Programmable Interfaces

Programmable interfaces present an opportunity for overflows that usually boils down to assumptions. Often, the programmer who created the interface doesn t document his or her assumptions, and the programmer who uses the interface makes different assumptions. Let s consider the example of an interface that processes a file. If the interface contains a method ReadFile(char *szFileName) and it is documented that MAX_PATH is the maximum size of the filename, what happens when MAX_PATH changes from 256 to 260 for a different compiler? Figure 8-10 shows one example of problems that can arise when documentation is vague and interface or function declarations change over time. In the figure, on the left, the caller is assuming MAX_PATH is defined one way, whereas the older component on the right is assuming it is defined differently.

image from book
Figure 8-10: Problems that can arise when interface or function declarations change over time

Is the overflow caused by the problem shown in Figure 8-10 the ReadFile function s fault for not doing data validation? Although the new component can fix this by making sure no more than 256 bytes are passed in, that won t fix existing callers . At this point, it would make sense to fix ReadFile , but what if the same programmers didn t write that code? The only way to fix the problem in that case is to audit the code to look for other callers of ReadFile to make sure they are not vulnerable to the same issue and warn developers to be careful when using this ReadFile function.

Over time, people are discovering a lot of functions that are unsafe or promote unsafe coding practices inasmuch as using them tends to result in buffer overflows. These functions have such an incredibly bad record that we can often successfully look for overruns by finding these functions and analyzing how they work and from where the data used in them comes. General guidelines for creating new APIs are as follows :

  • The API itself should either take a length for the data or a buffer size as a parameter.

  • The API should assume all parameters coming in are untrusted and do its own validation.

  • It should be very clear whether the length is a count of bytes or characters. In the case ofcharacters, it is also worth clarifying the type of characters (multibyte, single byte, Unicode, and so forth) and how big each character is.

  • The API should never assume the buffer allocated is longer than the data in it without a specific parameter telling it otherwise .

  • Assumptions should be documented with great care. Imagine if the ReadFile API had documented the length requirement as 256 (and put MAX_PATH in parentheses); it would have helped developers a bit.

  • API testers should hammer the API directly with good test cases.



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