580

Arbitrary Copy:
Bypassing Buffer-Overflow Protections
Krerk Piromsopa, Member, IEEE, and Richard J. Enbody, Member, IEEE

methods to protect systems from buffer-overflow attacks.

Abstract- Recent advances in buffer-overflow protection are Most of them are not able to provide complete protection. For
able to eliminate several common types of buffer-overflow example, some only prevent the original stack-smashing
attacks (e.g. stack smashing, jump table). In this paper, we attack, but can be circumvented by more recent attacks.
introduce arbitrary copy, a type of buffer-overflow attack that is The goal of this paper is to provide a rudimentary
capable of bypassing most buffer-overflow solutions. By
overflowing both source and destination pointers of any string understanding of arbitrary copy attacks. We begin with
copy (or similar) function, arbitrary copy is able to utilize a background of buffer-overflow attacks and current protection
useful local address for attacking a system. This method can schemes. Next, we examine the arbitrary copy and its potential
bypass even the most promising buffer-overflow protection that threat. Later is the analysis of a possible solution.
enforces the integrity of address such as Secure Bit 1241 and
MINOS 181. Later, we analyze conditions necessary for the
success of this attack. Though satisfying all necessary conditions
for this attack should be difficult, our conclusion is that it is a II. BACKGROUND
potential threat and requires consideration. This section begins by reviewing the characteristics of
buffer-overflow vulnerabilities and attacks. Later we briefly
Index Terms-Buffer overflow, Buffer-Overflow Attacks, analyze current solutions against buffer-overflow attacks. In
Computer security, Intrusion Detection, Intrusion Prevention
particular, we will focus on a promising approach, namely
input protection.
INTRODUCTION
I. A. Buffer-Overflow Attacks
JN this paper, we will present a type of buffer-overflow Buffer-overflow attacks occur when a malformed input is
'attack that is able to bypass most buffer-overflow being used to overflow a buffer causing a malicious or
protections. We refer to this attack as "arbitrary copy". unexpected result. Some metadata is necessary for prevention
Arbitrary copy is an attack on two data pointers. The [13].
successful attack allows an attacker to copy data from one There are two main targets of buffer-overflow attacks:
location to another arbitrarily. control data and local variables. In the vast majority of attacks,
Although, they date back to the infamous MORRIS worm control data is the target so prevention schemes have focused
of 1988 [26], buffer-overflow attacks remain the most on control data. Control data can be divided into several types:
common. Though skilled programmers should write code return addresses, function pointers, and branch slots. Return
without buffer overflows, no program is guaranteed free from addresses have been the primary target since their location can
bugs so it cannot be considered completely secure against easily be guessed. More advanced buffer-overflow attacks
buffer-overflow attacks. The persistence of buffer-overflow target other control data. Some literature refers to attacks on
vulnerabilities speaks to the difficulty of eliminating them. In return addresses as first-generation attacks, and those on
addition, as buffer overflow vulnerabilities are eliminated in function pointers as second-generation attacks [3].
operating systems, they are being found and exploited in
applications. When applications are run with root or B. Current Protection Schemes
administrator privileges the impact of a buffer overflow is
equally devastating. Current approaches against buffer-overflow attacks can be
In an effort to avoid relying on individual programming partitioned into three broad categories: static analysis,
skill, a number of researchers have proposed a variety of dynamic solutions, and isolation. Static analysis tries to fix
functions that are vulnerable to buffer-overflow attacks.
Dynamic approaches monitor or protect data that is either a
K. Piromsopa is a Ph.D. student in the Department of Computer Science target or the source of buffer-overflow attacks. Isolation seeks
and Engineering, Michigan State University, East Lansing, MI 48824 USA to limit the damage of attacks.
(corresponding author to provide phone: 517-353-3148; fax: 517-432-1061; e-
mail: piromsop 0cse.msu.edu). The main idea of "Static analysis" is to find and solve the
R. J. Enbody is with the Department of Computer Science and problem before deploying the program. To do so, we first
Engineering, Michigan State University, East Lansing, MI 48824 USA. (e- analyze the source code or disassembly of the program by
mail: enbody 0cse.msu.edu).
looking for code with a predefined signature. Examples of
 581
tools in this category are: ITS4 [30], FlawFinder [11], RATS Instead of protecting the data directly, obfuscation schemes
[25], and STOBO [14] reorganize memory to obscure memory making malicious
Knowing which data are critical to attacks, we can prevent manipulation of memory through buffer overflows more
attacks by validating the integrity of that data. As mentioned difficult. These schemes assume that attackers rely on a
above, the data of interest are control data such as (but not certain snapshot of addresses to overflow the critical data. If
limited to) return addresses. We name these "Dynamic the snapshot is random or difficult to guess, an attack is more
Solutions" because data are dynamically managed and verified difficult. Address Obfuscation [1] and ASLR [22] are good
in the run-time environment. We will further elaborate the examples.
tools in this category later. Taxonomy and more details of buffer-overflow protection
Isolation schemes isolate the attacker either to eliminate an schemes can be found in a survey of buffer-overflow
attack vector or to contain damage after a successful attack. protection [24].
Preventing the execution of code in stack memory isolates the
stack from the attacker. Alternatively, limiting the memory of
C. Input Protection
a process can isolate a compromised process. NX
nonexecutable memory is an example of the former while Input protection schemes are dynamic solutions against
sandboxing is an example of the latter. Examples include buffer-overflow attacks. The underlying assumption is that
AMD NX [19], non-executable stack [28], SPEF [18], and input data should be treated differently from local data, and
sandboxing. should not be used as control data. We will review four
In a survey of buffer-overflow protection [24], it is methods: Minos [8] and [9], Tainted Pointer [2], Dynamic
suggested that metadata is necessary for validating the Flow Tracking [29], Dynamic Taint Analysis [21], and Secure
integrity of data. While the assumptions of critical data and the Bit [23] that share the same assumption, but different
methods for storing and validating metadata vary from one implementations. Minos views data across segments as input.
solution to another, dynamic solutions can be classified into Tainted Pointer considers data passed from the operating
four groups: system as input. Dynamic Flow Tracking relies on operating
* Address Protection systems for marking input. Secure Bit treats data passing
* Input Protection between processes through the kernel as input.
* Bounds Checking In addition to addresses, Tainted Pointer also tried to
prevent input from being used as a pointer. However, input is
* Obfuscation sometimes used as a part of pointer arithmetic (e.g. indexing).
This aspect of Tainted Pointer may raise false alarms in many
The address protection schemes share the assumption that programs.
addresses (e.g. return address) are critical data and must be The other schemes protect a process from external control
tagged. In these schemes the metadata is created by functions data, but do not prevent buffer-overflow attacks on non-
that create the address (e.g. call instruction), and verified by control data. That raises the question: can an attacker use a
the many instructions that use the address (e.g. return buffer-overflow attack on non-control data to manipulate local
instruction). The schemes within this group are differentiated
control data to modify control flow?
by the types of metadata they use. Examples are StackGuard
[6], ProPolice [10], PointGuard [7], Hardware Supported
PointGuard [27], StackGhost [12], RAS [20], RAD [4], DISE III. ARBITRARY CoPY
[5], SCACHE [16].
The input protection schemes are latest and most promising.
These schemes assume that external data are untrustworthy There exists an arbitrary copy primitive which may allow
and should not be used as internal control data. The attackers to modify control flow without using external control
underlining concept is that "All input is evil until proven data. Using strcpy one can construct a vulnerable routine such
otherwise" [15]. In most cases, metadata are tightly coupled to that using a buffer-overflow to modify source and destination
the data in hardware (e.g. tagged memory). Data from external pointers, an attacker can arbitrarily copy any data from one
sources are tagged so it can be recognized, if there is an
location to another. This technique allows an existing piece of
attempt to use it as control data. Implementing the metadata in control data, an address with no Secure Bit set, to overwrite
hardware makes attacking the protocol difficult maybe another piece of control data. The result is control flow other
impossible. The schemes in this group differ in the than what the original programmer intended. Necessary
management of metadata. In the next section, we will focus on conditions for the success of this type of attack are:
this approach.
Rather than tagging data, bounds checking schemes 1. A vulnerable copy function such that a user can
explicitly bound buffers to prevent overflow. In this case, the modify both arguments (source and destination
metadata is associated with every block of allocated data and pointers) (possibly using buffer-overflow attacks)
is used to bound accesses. The notable tools are Array Bounds as exemplified in Figure 1.
Checking [17], Segmentation, and type-safe programming 2. The (useful) control data is stored in the local
languages. memory area.
 582
external data only internal data is used. Note that the damage
char *src,*dest; in this example is to create an infinite loop or crash the
char buff[10]; program, effectively a denial of service to the process.
While most internal data targets will be benign, one can
gets(buff); imagine malicious possibilities, even if they are a bit far-
fetched. For example, if for some reason a programmer
strcpy(src,dest); created a function pointer to shell and had both a vulnerable
Figure 1 Vulnerable code copy routine and no optimization; one could copy that shell
pointer elsewhere to allow a shell call someplace different
than the programmer intended. Note that the desired
Both of these conditions must be true. If one fails, the attack privileged-elevated shell is not possible with this attack
fails. Though the first condition could be satisfied in any because the best buffer-overflow prevention schemes will
arbitrarily program, the code generated by the compiler will prevent privilege-elevation attacks. Alternatively, (again with
likely render the attack impossible. For example, any level of a vulnerable copy routine and no optimization) if one had
optimization will use registers for storing the source and function pointers to both an authorization "accept" function
destination variables. If either or both are in registers, a buffer- and a "reject" function one might be able to redirect program
overflow to modify both variables will fail. We will analyze flow to subvert an authorization routine to the "accept"
the possible cases where both conditions concurrently occur function when the "reject" function was expected.
later.

A. Example
To ease understanding, Figure 2 presents a sample case of
an attack on non-control data where the vulnerability might be
applicable.
int b() {
char *src,*dest;
char buff[10];
printf("Input string:.\n");
// Overflow *src, *dest
gets(buff);
// Copy src to dest
strcpy(src,dest);
}
int a() Figure 3 a possible scenario
bo);
IV. ISSUES
} Consider the second condition of arbitrary copy: the
int main (int argc,char *argv[]) presence of a useful address in local memory. We know that a
ao); mechanism like Secure Bit prevents the use of input as control
} data, thus only purely local data that is not derived from input
Figure 2 Sample Buffer-Overflow attacks on non- is a potential threat. One's first thought might be that any
function call could provide an address of that function.
control data However, because of relocation, local calls use relative
addresses which cannot be used for this attack. Other sources
In this example, main calls function "a" which then calls of control targets such as jumps are also relative addresses and
the vulnerable function "b". Within "b" the user inputs buff not useful. Given this observation, potential sources of
which can overflow to both overwrite *src to point to the addresses are narrowed to the presence of a shared library or a
function pointer.
return address of a previous call (e.g. "a () ") and overwrite
*dest to point to the target address (e.g. return address of Shared library. In the case of shared libraries (the function
"b ()" or "main () "). Note that this overflow is possible only is located in the shared library), a call to the function means
if all optimization is turned off so that neither src nor dest there exists a useful entry in the Global Offset Table (GOT).
is in a register. Under these circumstances it is possible to
change the control flow without replacing control data with Function Pointer. The assignment of a function address to
 583
a function pointer (frequently found in C++) would create a VI. CONCLUSIONS
pointer available for reuse. Arbitrary copy is a potential threat that can bypass current
state-of-the-art buffer-overflow protection schemes. While
If a useful address is stored as an entry in the GOT or a other (easier) vectors of attacks still exist, it is unlikely that
function pointer, the buffer-overflow described above can be arbitrary copy will be used as a tool. However, the recent
used to replace a target address with this address. Target advances in buffer-overflow protection will make existing
addresses might be return addresses, function pointers, or an attacks obsolete. While trivial optimization eliminates the
entry in GOT itself. threat, one cannot count on non-optimization as a complete
The probability that all conditions are applicable is solution. We should pay a close attention to this problem.
considered to be low. In fact, some researchers [8] do not We are now working on extending Secure Bit to protect
believe that it will be a problem or suggest that encoding against buffer-overflows of non-control data. In addition to
addresses in GOT should be sufficient for preventing the the broader protection provided, this specific attack can be
attack. However, that prevention might not be able to protect prevented by preserving the integrity of the source and
some function pointers in C++. destination pointers from illegal modification. The common
practice of using user input as array indices complicates
identifying illegal modification.
V. POSSIBLE SOLUTIONS
Though the attack sounds probabilistically low, it is not
impossible, and experience suggests that no matter how REFERENCES
remote the possibility, someone, sometime will exploit it. We
have already mentioned that the most simplistic optimization [1] S. Bhatkar, D. C. Duvarney, and R. Sekar, "Address Obfuscation: an
prevents the attack. To protect against this attack in the Efficient Approach to Combat a Broad Range of Memory Error
Exploits," In Proc. of the 12th USENIXSecurity Symposium. 2003.
presence of no optimization, we simply have to eliminate at [2] S. Chen, J. Xu, N. Nakka, Z. KalbarcZyk, and R. K. Iyer, "Defeating
least one critical condition. There are three possible methods. Memory Corruption Attacks via Pointer Taintedness Detection," in
* Prevent a raw address from being stored directly in Proc. Of IEEE International Conf on Dependable Systems and
Networks (DSN), Yokohama, Japan, June 28 - July 1, 2005
the program. [3] E. Chien, and P. Szor, "Blended Attacks Exploits, Vulnerabilities and
* Secure the target address from being modified (e.g. Buffer-Overflow Techniques in Computer Viruses," In Proc. of Virus
GOT and function pointers). Bulletin Conf, 2002
[4] T. Chiueh, F. Hsu, "RAD: A Compile-Time Solution to Buffer Overflow
* Validate that both the source and destination Attacks," In Intl. Conf on Distributed Computing Systems, 2001.
pointer have not been maliciously modified. [5] M.L. Corliss, E.C. Lewis, and A. Roth, "Using DISE to Protect Return
Rather than storing an address directly into the GOT table Addresses from Attack," ACMSIGARCH, Vol 33. No. 1, 2005.
[6] C. Cowan, S. Beattie, R.F. Day, C. Pu, P. Wagle, and E. Walthinsen,
or function pointer, we may choose to store an encoded "Protecting Systems from Stack Smashing Attacks with StackGuard,"
version of an address or store a relative address. Even a trivial the Linux Expo, Raleigh, NC,1999
encoding such as XOR (like PointGuard [7]) with some [7] C. Cowan, S. Beattie, J. Johansen, and P. Wagle, "PointGuard:
Protecting Pointers From Buffer Overflow Vulnerabilities," In Proc. of
constant would be sufficient. However, this approach does not the 12th USENIXSecurity Symposium, 2003
prevent a copy between locations that share the same encoding [8] J.R. Crandall, and F.T. Chong, "Minos: Control Data Attack Prevention
scheme or key used to encrypt the address (e.g. between Orthogonal to Memory Model," Intl. Sym. on Microarchitecture, 2004.
[9] J.R. Crandall, and F.T. Chong, "A Security Assessment of the Minos
function pointers or entries in the GOT). Note that PointGuard Architecture," ACM SIGARCH, Vol 33. No. 1, 2005.
[7] can be used to reduce the probability of overwriting source [10] J. Etoh, "GCC extension for protecting applications from stack-
and destination pointers. However, if the key and algorithm smashing attacks," IBM, 2000.
[11] Flawfinder, Available: la e
can be circumvented, it is possible to overwrite it with a valid [12] M.S. Frantzen, "StackGhost: Hardware facilitated stack protection," In
copy. In fact, we may be able to overflow the value (e.g. Proc. of the 10th USENIXSecurity Symposium, 2000.
index) that is used for pointer arithmetic rather than modifying [13] A. Glew, "Segments, Capabilities, and Buffer Overrun Attacks,"
Computer Architecture NEWS, ACM SIG Computer Architecture
the pointer directly. Vol.31, No.4 - September 2003, pp. 26 - 31
Rather than making the useful address useless, we can [14] E. Haugh, and M. Bishop, "Testing C Programs for Buffer Overflow
protect the target from being modified. In the case of GOT, we Vulnerabilities," In Proc. of the 2003 Symposium on Networked and
can protect the GOT from being a target by declaring it as
Distributed System Security (SNDSS 2003) (Feb. 2003)
[15] M. Howard, D. Leblance, Chapter 10:All Input Is Evil!. Writing Secure
read-only after the shared library is configured. Nonetheless, Code, Microsoft Press, 2nd ed.(1965)
we cannot apply the same idea to protect function pointers or [16] K. Inoue, "Energy-Security Tradeoff in a Secure Cache Architecture
return addresses in general. Against Buffer Overflow Attacks," ACM SIGARCH, Vol 33. No. 1,
2005.
Alternatively, we can validate (assert) the source and [17] R.W.M. Jones, and P.H.J. Kelly, "Backwards-compatible bounds
destination pointers before running the "strcpy(..)" function. If checking for arrays and pointers in C programs," In The 3rd Intl.
the source and destination pointers can be validated, the attack Workshop on Automated Debugging, 1997.
[18] D. Kirovski, M. Drinic, and M. Potkonjak, "Enabling Trusted Software
can be prevented. However, a false alarm may be generated Integrity," ACM Intl. Conf on Architectural Support for Programming
when a pointer is the arithmetic result of input. Languages and Operating Systems, 2002.
[19] T. Krazit, "PCWorld - News - AMD Chips Guard Against Trojan
Horses," IDG News Service, 2004.
 584
[20] J.P. Mcgregor, D.K. Karig, Z. Shi, R.B. Lee, "A Processor Architecture
Defense against Buffer Overflow Attacks," In Proc. of the IEEE Intl.
Conf on Information Tech.: Research and Education (ITRE 2003), 243-
250.
[21] J. Newsome, and D. Song, "Dynamic Taint Analysis: Automatic
Detection and Generation of Software Exploit Attacks," In NDSS (Feb,
2005)
[22] PAX TEAM. 2003. Documentation for the PaX project
[23] K. Piromsopa, and R. Enbody, "Secure Bit2: Transparent, Hardware
Buffer-Overflow Protection," Technical Reports #MSU-CSE-05-9,
Department of Computer Science and Engineering, Michigan State
University, 2005.
[24] K. Piromsopa, and R. Enbody, "Survey of Buffer-Overflow Protection,"
Technical Reports #MSU-CSE-06-3,, Department of Computer Science
and Engineering, Michigan State University, 2006.
[25] RATS, Available: t wst
[26] C. Schmidt, and T. Darby, "The What, Why, and How of the 1988
Internet Worm," Available:
[27] Z. Shao, Q. Zhuge, Y. He, and E.H. Sha, "Defending Embedded
Systems Against Buffer Overflow via Hardware/Software," In Proc. of
the 20th Annual Computer Security Applications Conference, Tucson,
Arizona (Dec. 6-10, 2004)
[28] SOLAR DESIGNER, Linux kernel patch from the Openwall Project
(Non-Executable User Stack), 2002. Available:
[29] G. Suh, J. Lee, and S. Devadas, "Secure program execution via dynamic
information flow tracking," In ASPLOSXI (Oct, 2004.)
[30] J. Viega, J.T. Bloch, Y. Kohno, and G. Mcgraw, "ITS4: A Static
Vulnerability Scanner for C and C++ Code," In Proc. of the 16th Annual
Computer Security Applications Conference, 2000.