2009 International Conference on Availability, Reliability and Security

Protecting global and static variables from buffer overflow attacks

Yves Younan Frank Piessens Wouter Joosen

DistriNet, Department of Computer Science
Katholieke Universiteit Leuven
Celestijnenlaan 200a, B3001 Leuven, Belgium
E-mail: {yvesy,frank,wouter}@cs.kuleuven.ac.be

Abstract strong overflow protection against dynamically, automati-

cally and statically allocated memory. A major advantage
Many countermeasures exist to protect the stack and of these countermeasures is that they can be applied au-
heap from code injection attacks, however very few counter- tomatically without programmer intervention, they are au-
measures exist that will specifically protect global and static tomatically added when compiling and linking with these
variables from attack. In this paper we suggest a way of countermeasures.
protecting global and static variables from these type of at- The paper is structured as follows: Section 2 describes
tacks, with negligible performance and memory overheads. how a buffer overflow in this region can be used by an at-
Our approach is based on the idea of separating data in de tacker to gain control of the execution flow. Section 3 de-
data segment based on its type. These separated areas are scribes the main design principles of our countermeasure,
then protected from each other by a guard page. This pre- while Section 4 discusses limitations and how we plan to
vents a buffer overflow from overwriting data or code point- implement the countermeasure. Section 5 compares our ap-
ers, in turn preventing attackers from being able to perform proach to other approaches. Finally, section 6 contains our
a code injection attack. conclusion.

2 Static and global variables

1 Introduction
In this section we describe how the memory that stores
Vulnerabilities that could lead to code injection attacks
static and global variables is organized and then examine
are a significant threat to the security of a system. The most
how an attacker could use a buffer overflow on one of this
common form of code injection attack is the stack based
variables to gain control of the execution flow on the IA32
buffer overflow and many countermeasures [39] exist that
architecture [15].
protect against this attack. The heap is also a source of
buffer overflows and there are some countermeasures that
will protect the heap from attack, however very few coun- 2.1 Memory layout
termeasures currently exist that will protect global and static
variables from these types of attack. Figure 1 depicts the memory layout of a Linux process
In [40] we describe a global approach to protect against on the IA32 architecture. Code is stored in the text segment,
code injection attacks by separating data that the operating while local (automatic) variables are stored on the stack.
system relies on from regular user data. This technique has Global, static data and the heap (dynamic memory) are all
proven succesful from a security perspective as well as from stored in the data segment. The data segment however also
a performance perspective in protecting against heap-based contains other important information that the operating sys-
[42] and stack-based [41] overflows. While the basic idea tem relies on to execute the program.
of separating user data from system data is the same in these Figure 2 provides an overview of the layout of the data
two countermeasures, the actual approaches that need to be segment of a typical program. Static and global variables
taken to separate the data turn out to be quite different. In which have been initialized at compile time are stored in
this paper we describe the details of how to apply this sepa- the data section, followed by the section containing the ex-
ration idea to protect against attacks on global or static vari- ception handling frame, which holds information needed
ables. Combining these three countermeasures leads to a to handle exceptions in languages that support them (like

978-0-7695-3564-7/09 $25.00 © 2009 IEEE 798

DOI 10.1109/ARES.2009.126
 C++). This section is followed by the ctors and dtors sec-
tions, these execute registered functions at respectively pro-
gram start and program finish. Next, is the global offset
table, which is used by position independent code1 to ad-
dress absolute memory locations. Its values are set by the
runtime linker when new code is loaded, it also holds ab-
solute memory addresses for library functions. Static and
Text global variables which have not been initialized are stored
in the bss section, they are initialized to 0 in this area.
Data

2.2 Exploitation

If attackers can overflow a variable in the data section,

Stack they could easily overwrite data stored in the other sections.
Two favorite targets of attackers are the dtors and the got
sections.
Figure 1. Basic memory layout on Linux/IA32 The dtors section is comprised of a list of pointers to
functions to execute when the program terminates, termi-
nated with a NULL. If an attacker can overwrite these point-
ers, his code will be executed when the program terminates
[30].
The global offset table contains the absolute address of
shared library functions which are used by the procedure
linkage table to execute functions which have to be loaded
from a shared library at runtime. If an attacker modifies the
address of one of these functions (e.g. the printf function)
to point to injected code, the program will execute that code
when the library function is supposed to be called.
Overflows in the bss section can not overwrite any of the
other sections because the bss section is stored last. How-
ever, immediately following the bss section is the heap, thus
data an attacker could use an overflow in the bss section to per-
eh_frame
form a heap-based buffer overflow [33] which could also
allow him to gain control of the execution flow.
ctors

dtors
3 Countermeasure
got

bss In this section we propose a countermeasure which could

protect against these types of attack. By separating the data
which can be used by an attacker to perform a code injec-
Heap
tion attack from data which could modify control flow if
changed, we can protect against this type of attack. The
concept of this countermeasure is straightforward: by reor-
ganizing the data segment and making sure that all impor-
Figure 2. Layout of the data segment tant information comes before any arrays, we can prevent
most attacks. We make sure that these arrays can not write
into the heap by placing a guard page2 between the last ar-
1 PIC is code that can be loaded at any address, it does not address any

absolute memory locations

2 A guard page is page of memory where no permission to read or to

write has been set. Any access to such a page will cause the program to
terminate.

799
 eh_frame
the risk they pose if they are a target for attack), overflow-
able (ordered from less likely to overflow to more likely)
ctors but also a target of attacks and just overflowable (ordered
dtors by how likely they will overflow).
Pointers could be overwritten to perform a code injection
got
attack, but are not exploitable on their own, so we place
data pointers them in the first category. Integers can hold pointers or
data integers can be used as offsets to a pointer, so they could also be
data struct/union used to perform indirect pointer overwrites. Although they
(no arrays) are overflowable, they will never use more than the mem-
data floats ory allocated for them since they will wrap around zero on
data arrays of pointers overflow, as such we can place them in the same category
as pointers. Structures and unions that do not contain any
data arrays of integers
arrays come next, they could contain pointers that could
data struct/union with
arrays (not of char)
be overwritten, but do not contain any arrays so they are
data arrays of struct/union not overflowable. The last element of the first category are
with arrays (not of char)
data struct/union with
floats, they are not overflowable and are also not a likely
arrays of char target for attack.
data arrays of struct/union
with arrays of char
The second category contains data which can overflow
data arrays of floats
in theory, but which could also be used to perform an indi-
rect pointer overwrite. This data is sorted by the risk posed
data arrays of characters if it is attacked: higher risk data is stored first so that if an
guard page overflow occurs, it can only overwrite equally or less risky
bss (same layout as data)
data. The first element in this category are arrays of pointer,
followed by arrays of integers. Next we place structures
guard page and unions which contain arrays, but not arrays of charac-
ters, arrays of these structures and unions, structures and
unions which contain arrays of characters and finally arrays
Heap
of these structures.
The third category only contains data which is overflow-
able, ordered by how likely they are to be overflown. The
first elements stored here are arrays of floats, these do not
Figure 3. Modified layout of the data segment contain information which could easily lead to a code injec-
tion attack and could overflow. Arrays of characters, which
are most often targeted by attackers, because they are of-
ten used with vulnerable string manipulation functions (e.g.
ray and the heap3 . Since the size of the data segment is
strcpy), are placed last.
known at compile time, adding such a guard page at load
The data layout that these three categories provide are
time does not introduce any problems.
used for both the data and bss sections which are stored
Figure 3 illustrates the modified memory layout: first is
next to each other. To protect the bss section from the arrays
the memory which only contains data used by the loader:
of characters from the data section, we place a guard page
the constructors, destructors, global offset table, the excep-
between the two sections.
tion handling frame, etc. Since a program should not be
By separating the data which can influence control from
able to change them, these can be stored at the start of the
data which is can be modified by the user, we can protect
segment. While a major avenue for attack has been closed
against buffer overflow attacks in these sections.
off by preventing arrays from overflowing into the destruc-
tors section and the global offset table, an attacker could still
use an overflow in the data or bss section to overwrite data 4 Discussion
in that section. To prevent this from occurring we divide
the data into three categories: not-overflowable (ordered by It may still be possible to perform a code injection at-
3A
tack using a buffer overflow on a structure that contains
page on IA32 is 4096 bytes, this means that if we want to add a
guard page, the memory preceding the guard page will need to be aligned
both an array of characters and a pointer since these types
on 4096 bytes. Adding such a page after all memory locations would be of structures will be stored in a contiguous region of mem-
introduce a prohibitive memory overhead [29] ory. This is a limitation of the approach that can not easily

800
be fixed because the C standard[18] mandates that all struc- 5.1 Alternative approaches
tures must be stored in order in contiguous memory. Many
other countermeasures, including bounds checkers suffer Many alternative approaches exist that try and protect
from this limitation. Given that correct code can rely on this against buffer overflow attacks. In this section we will
feature of the C language, it is hard to protect against such briefly discuss the most important types of countermea-
an attack. To reduce the risk of attack, we treat structures sures. A more extensive discussion can be found in [38, 12].
containing arrays of characters different from other struc-
tures: by storing them below regular structures. While this
does not solve the problem, it reduces the risk of successful 5.1.1 Probabilistic countermeasures
exploitation because attackers can only overflow informa- Many countermeasures make use of randomness when pro-
tion stored below this type of structure. tecting against attacks. Many different approaches ex-
Integer errors could also be used to perform a buffer ist when using randomness for protection. Canary-based
overflow because they could be used to overwrite arbitrary countermeasures [9, 13, 23, 31] use a secret random num-
memory locations, without requiring a contiguous buffer ber that is stored before an important memory location:
overflow. This would bypass the protection provided by the if the random number has changed after some operations
guard page. This is an important limitation in our approach have been performed, then an attack has been detected.
and must be taken into account when applying this counter- Memory-obfuscation countermeasures [8, 5] encrypt (usu-
measure. ally with XOR) important memory locations or other infor-
mation using random numbers. Memory layout randomiz-
Implementation of this countermeasure will require
ers [35, 4, 36, 6] randomize the layout of memory: by load-
some substantial modifications to the compiler, the linker
ing the stack and heap at random addresses and by placing
and the loader, however because only the layout is changed,
random gaps between objects. Instruction set randomizers
it should not bring any extra performance overhead with it.
[3, 19] encrypt the instructions while in memory and will
Because the size of all the sections are known at load time,
decrypt them before execution.
changing the layout will not add much memory overhead ei-
While these approaches are often efficient, they rely on
ther: each section followed by a guard page will have to be
keeping memory locations secret. However, programs that
aligned to page size, which means that the maximum over-
contain buffer overflows could also contain ”buffer over-
head per section would be 4095 bytes (if only 1 byte is used
reads” (e.g. a string which is copied via strncpy but not
on the last page of that section). Since only 2 guard pages
explicitly null-terminated could leak information) or other
are used, the countermeasure has a maximum overhead of
vulnerabilities like format string vulnerabilities, which al-
8190 bytes. The guard pages themselves will only take up
low attackers to print out memory locations. Such memory
virtual memory, since they are not accessed, no physical
leaking vulnerabilities could allow attackers to bypass this
memory is consumed.
type of countermeasure.

5.1.2 Bounds checkers

5 Related work
Bounds checking [20, 34, 2, 17, 25, 27, 32, 28] is a better
solution to buffer overflows, however when implemented
for C, it often has a severe impact on performance or may
Not many countermeasures exist that specifically try to cause existing code to become incompatible with bounds
protect this type of data. Although some of the more global checked code.
approaches (like bounds checking) will also protect global
and static variables. In this section we will first discuss
the only other countermeasure that specifically targets this 5.1.3 Safe languages
memory and will then briefly discuss the more global ap-
Safe languages are languages where it is generally not pos-
proaches.
sible for any known code injection vulnerability to exist
Drepper [11] implemented a countermeasure which re- as the language constructs prevent them from occurring.
organizes the data segment so that the data and bss sections A number of safe languages are available that will pre-
are placed similarly to the way we describe earlier. How- vent these kinds of implementation vulnerabilities entirely.
ever he does not reorganize the data within these sections There are safe languages [16, 14, 26, 24, 10, 22, 37] that
so arrays of characters could still overwrite pointers in these remain as close to C or C++ as possible, these are gener-
sections. He also does not add guard pages which will pro- ally referred to as safe dialects of C. While some safe lan-
tect the heap from being attacked by the bss section. guages [7, 37] try to stay more compatible with existing C

801
programs, use of these languages may not always be practi- Proceedings of the 10th ACM Conference on Computer
cal for existing applications. and Communications Security (CCS2003), pages 281–289,
Washington, District of Columbia, U.S.A., Oct. 2003. ACM.
[4] S. Bhatkar, D. C. DuVarney, and R. Sekar. Address obfus-
5.1.4 Execution monitors cation: An efficient approach to combat a broad range of
In this section we describe two countermeasures that mon- memory error exploits. In Proceedings of the 12th USENIX
Security Symposium, pages 105–120, Washington, District
itor the execution of a program and prevent transferring
of Columbia, U.S.A., Aug. 2003. USENIX Association.
control-flow which could be unsafe.
[5] S. Bhatkar and R. Sekar. Data space randomization. In Pro-
Program shepherding [21] is a technique that monitors ceedings of the 5th Conference on Detection of Intrusions
the execution of a program and will disallow control-flow and Malware & Vulnerability Assessment, volume 5137 of
transfers4 that are not considered safe. An example of a Lecture Notes in Computer Science, Paris, France, July
use for shepherding is to enforce return instructions to only 2008. Springer.
return to the instruction after the call site. The proposed [6] S. Bhatkar, R. Sekar, and D. C. DuVarney. Efficient tech-
implementation of this countermeasure is done using a run- niques for comprehensive protection from memory error ex-
time binary interpreter. As a result, the performance impact ploits. In 14th USENIX Security Symposium, Baltimore,
of this countermeasure is significant for some programs, but MD, August 2005. USENIX Association.
acceptable for others. [7] J. Condit, M. Harren, S. McPeak, G. C. Necula, and
Control-flow integrity [1] determines a program’s con- W. Weimer. CCured in the real world. In Proceedings
of the ACM SIGPLAN 2003 Conference on Programming
trol flow graph beforehand and ensures that the program
Language Design and Implementation, pages 232–244, San
adheres to it. It does this by assigning a unique ID to each Diego, California, U.S.A., 2003. ACM.
possible control flow destination of a control flow transfer. [8] C. Cowan, S. Beattie, J. Johansen, and P. Wagle. Point-
Before transferring control flow to such a destination, the Guard: protecting pointers from buffer overflow vulnera-
ID of the destination is compared to the expected ID, and bilities. In Proceedings of the 12th USENIX Security Sym-
if they are equal, the program proceeds as normal. This ap- posium, pages 91–104, Washington, District of Columbia,
proach, while strong and in the same efficiency range as our U.S.A., Aug. 2003. USENIX Association.
approach, does not protect against non-control data attacks. [9] C. Cowan, C. Pu, D. Maier, H. Hinton, J. Walpole, P. Bakke,
S. Beattie, A. Grier, P. Wagle, and Q. Zhang. Stack-
Guard: Automatic adaptive detection and prevention of
6 Conclusion buffer-overflow attacks. In Proceedings of the 7th USENIX
Security Symposium, pages 63–78, San Antonio, Texas,
Many countermeasures exist to protect against attacks on U.S.A., Jan. 1998. USENIX Association.
stack-based buffer overflows, however only very few exist [10] D. Dhurjati, S. Kowshik, V. Adve, and C. Lattner. Memory
that will effectively protect against attacks on global and safety without runtime checks or garbage collection. In Pro-
static variables with a low performance overhead. In this ceedings of the 2003 ACM SIGPLAN Conference on Lan-
guage, Compiler, and Tool Support for Embedded Systems,
paper we suggested an approach which would better pro-
pages 69–80, San Diego, California, U.S.A., June 2003.
tect this region of memory from attack while only having ACM.
negligible performance and memory overhead. [11] U. Drepper. Security enhancements in redhat enterprise
linux (beside selinux). http://people.redhat.
References com/drepper/nonselsec.pdf, Dec. 2005.
[12] U. Erlingsson. Low-level software security: Attacks and
defenses. Technical Report MSR-TR-2007-153, Microsoft
[1] M. Abadi, M. Budiu, U. Erlingsson, and J. Ligatti. Control-
Research, Nov. 2007.
flow integrity. In Proceedings of the 12th ACM Conference
[13] H. Etoh and K. Yoda. Protecting from stack-smashing at-
on Computer and Communications Security, pages 340–
tacks. Technical report, IBM Research Divison, Tokyo Re-
353, Alexandria, Virginia, U.S.A., Nov. 2005. ACM.
search Laboratory, June 2000.
[2] T. M. Austin, S. E. Breach, and G. S. Sohi. Efficient de-
[14] D. Grossman, G. Morrisett, T. Jim, M. Hicks, Y. Wang, and
tection of all pointer and array access errors. In Proceed-
J. Cheney. Region-based memory management in cyclone.
ings of the ACM SIGPLAN ’94 Conference on Programming
In Proceedings of the 2002 ACM SIGPLAN Conference on
Language Design and Implementation, pages 290–301, Or-
Programming Language Design and Implementation, pages
lando, Florida, U.S.A., June 1994. ACM.
282–293, Berlin, Germany, June 2002.
[3] E. G. Barrantes, D. H. Ackley, S. Forrest, T. S. Palmer,
[15] Intel Corporation. IA-32 Intel Architecture Software Devel-
D. Stefanović, and D. D. Zovi. Randomized instruction
oper’s Manual Volume 1: Basic Architecture, 2001. Order
set emulation to disrupt binary code injection attacks. In
Nr 245470.
4 Such a control flow transfer occurs when e.g., a call or ret instruction [16] T. Jim, G. Morrisett, D. Grossman, M. Hicks, J. Cheney, and
is executed. Y. Wang. Cyclone: A safe dialect of C. In USENIX Annual

802
 Technical Conference, pages 275–288, Monterey, Califor- [31] W. Robertson, C. Kruegel, D. Mutz, and F. Valeur. Run-
nia, U.S.A., June 2002. USENIX Association. time detection of heap-based overflows. In Proceedings
[17] R. W. M. Jones and P. H. J. Kelly. Backwards-compatible of the 17th Large Installation Systems Administrators Con-
bounds checking for arrays and pointers in C programs. In ference, pages 51–60, San Diego, California, U.S.A., Oct.
Proceedings of the 3rd International Workshop on Auto- 2003. USENIX Association.
matic Debugging, number 009-02 in Linköping Electronic [32] O. Ruwase and M. S. Lam. A practical dynamic buffer over-
Articles in Computer and Information Science, pages 13–26, flow detector. In Proceedings of the 11th Annual Network
Linköping, Sweden, 1997. Linköping University Electronic and Distributed System Security Symposium, San Diego,
Press. California, U.S.A., Feb. 2004. Internet Society.
[18] JTC 1/SC 22/WG 14. ISO/IEC 9899:1999: Programming [33] Solar Designer. JPEG COM marker processing vulnerability
languages – C. Technical report, International Organization in netscape browsers. http://www.openwall.com/
for Standards, 1999. advisories/OW-002-netscape-jpeg.txt, July
[19] G. S. Kc, A. D. Keromytis, and V. Prevelakis. Counter- 2000.
ing code-injection attacks with instruction-set randomiza- [34] J. L. Steffen. Adding run-time checking to the portable C
tion. In Proceedings of the 10th ACM Conference on Com- compiler. Software: Practice and Experience, 22(4):305–
puter and Communications Security (CCS2003), pages 272– 316, Apr. 1992. ISSN: 0038-0644.
280, Washington, District of Columbia, U.S.A., Oct. 2003. [35] The PaX Team. Documentation for the PaX project. http:
ACM. //pageexec.virtualave.net/docs/.
[20] S. C. Kendall. Bcc: Runtime checking for C programs. [36] J. Xu, Z. Kalbarczyk, and R. K. Iyer. Transparent run-
In Proceedings of the USENIX Summer 1983 Conference, time randomization for security. In 22nd International Sym-
pages 5–16, Toronto, Ontario, Canada, July 1983. USENIX posium on Reliable Distributed Systems (SRDS’03), pages
Association. 260–269, Florence, Italy, Oct. 2003. IEEE Computer Soci-
[21] V. Kiriansky, D. Bruening, and S. Amarasinghe. Secure ety, IEEE Press.
execution via program shepherding. In Proceedings of the [37] W. Xu, D. C. DuVarney, and R. Sekar. An Efficient and
11th USENIX Security Symposium, San Francisco, Califor- Backwards-Compatible Transformation to Ensure Memory
nia, U.S.A., Aug. 2002. USENIX Association. Safety of C Programs. In Proceedings of the 12th ACM
[22] S. Kowshik, D. Dhurjati, and V. Adve. Ensuring code safety SIGSOFT International Symposium on Foundations of Soft-
without runtime checks for real-time control systems. In ware Engineering, pages 117–126, Newport Beach, Califor-
Proceedings of the International Conference on Compilers nia, U.S.A., October-November 2004. ACM, ACM Press.
Architecture and Synthesis for Embedded Systems, pages [38] Y. Younan. Efficient Countermeasures for Software Vulner-
288–297, Grenoble, France, Oct. 2002. abilities due to Memory Management Errors. PhD thesis,
[23] A. Krennmair. ContraPolice: a libc extension for protecting Katholieke Universiteit Leuven, 2008.
applications from heap-smashing attacks. http://www. [39] Y. Younan, W. Joosen, and F. Piessens. Code injection in
synflood.at/contrapolice/, Nov. 2003. C and C++ : A survey of vulnerabilities and countermea-
[24] J. R. Larus, T. Ball, M. Das, R. DeLine, M. Fähndrich, sures. Technical Report CW386, Departement Computer-
J. Pincus, S. K. Rajamani, and R. Venkatapathy. Righting wetenschappen, Katholieke Universiteit Leuven, July 2004.
software. IEEE Software, 21(3):92–100, May/June 2004. [40] Y. Younan, W. Joosen, and F. Piessens. A methodology for
[25] K.-S. Lhee and S. J. Chapin. Type-assisted dynamic buffer designing countermeasures against current and future code
overflow detection. In Proceedings of the 11th USENIX Se- injection attacks. In Proceedings of the Third IEEE Interna-
curity Symposium, pages 81–90, San Francisco, California, tional Information Assurance Workshop 2005 (IWIA2005),
U.S.A., Aug. 2002. USENIX Association. College Park, Maryland, U.S.A., Mar. 2005. IEEE, IEEE
[26] G. Necula, S. McPeak, and W. Weimer. CCured: Type-safe Press.
retrofitting of legacy code. In Conference Record of POPL [41] Y. Younan, W. Joosen, and F. Piessens. Efficient protec-
2002: The 29th SIGPLAN-SIGACT Symposium on Princi- tion against heap-based buffer overflows without resorting
ples of Programming Languages, pages 128–139, Portland, to magic. In Proceedings of the International Conference
Oregon, U.S.A., Jan. 2002. ACM. on Information and Communication Security (ICICS 2006),
[27] Y. Oiwa, T. Sekiguchi, E. Sumii, and A. Yonezawa. Fail-safe Raleigh, North Carolina, U.S.A., Dec. 2006.
ANSI-C compiler: An approach to making C programs se- [42] Y. Younan, D. Pozza, F. Piessens, and W. Joosen. Ex-
cure: Progress report. In Proceedings of International Sym- tended protection against stack smashing attacks without
posium on Software Security 2002, pages 133–153, Tokyo, performance loss. In Proceedings of the Twenty-Second An-
Japan, Nov. 2002. nual Computer Security Applications Conference, Miami,
[28] H. Patil and C. N. Fischer. Low-Cost, Concurrent Checking Florida, U.S.A., Dec. 2006. IEEE Press.
of Pointer and Array Accesses in C Programs. Software:
Practice and Experience, 27(1):87–110, January 1997.
[29] B. Perens. Electric fence 2.0.5. http://perens.com/
FreeSoftware/.
[30] J. M. B. Rivas. Overwriting the .dtors section. Posted on the
Bugtraq mailinglist http://www.securityfocus.
com/archive/1/150396, Dec. 2000.

803