1. Fighting buffer overflows with Address Space Layout
Randomization
John-Andre Bjorkhaug
Gjovik University College
Master in Information Security
19. December 2013
It seem to be no end to the cat and mouse game between software the people who develop
applications, and the people who break them. As good as every time a programmer finds a
new method to protect against a security vulnerability, a very short time after, the protection
mechanism is broken. One of many protection mechanisms against vulnerabilities in modern
operating systems is Address Space Layout Randomization, which was created to avoid that an
adversary to know where in memory a program is working, and were standard libraries are located.
This paper will start by explaining short about other memory protection mechanisms like canaries,
No eXecute-bit, Data Execution Protection and shortly define what ASLR are in the introduction.
Then there will be a discussion on why it is necessary with protection mechanisms in memory, by
giving details about overflow attacks like stack overflow and heap overflow. Then there will be a
general description on how ASLR works, and general improvements from the original design. The
paper will end with a description on how ASLR is implemented in five of the most used operating
systems today, with the biggest focus on Microsoft Windows, and a small conclusion at the end.
Categories and Subject Descriptors: D.4.6 [Security and Protection ]: Invasive software—
Operating system security
General Terms: security
Additional Key Words and Phrases: operating system security, aslr, buffer overflows
1. INTRODUCTION
In the 1960s and 1970s stack buffer overflows were among the first vulnerabilities
to be exploited, and described academically [Anderson 1972, p. 61]. According to
[Anderson 2008, p- 118], in 2008 half of the technical attacks reported by CERT
bulletins and security mailing lists, were of some kind of buffer overflow. This might
explain why this sort of attacks by some is called the ”crown jewel of attacks”
[Hoglund and McGraw 2004, p- 277]. In the year of the writing of this paper, 2013,
buffer overflow are still among the vulnerabilities that is exploited most frequently in
the wild. Stack buffer overflows, and buffer overflows in general, is possible because
of the lack of proper boundary checking of variables in applications, which causes
memory corruption. In stack buffer overflows this makes it possible to overwrite
information on the stack, including the functions return address. By doing this the
program can be redirected to arbitrary code, known as shellode [Snow et al. 2013].
The year 1988 made this family of vulnerabilities more famous, with the unfortunate
outbreak of the Morris worm. The worm spread by exploiting a stack buffer overflow
vulnerability in the Unix service finger, in addition to some other vulnerabilities,

2. Fighting buffer overflows withAddress Space Layout Randomization · 2
and infected approximately 6000 computers, or about 10% of the total number of
computers connected to the Internet at the time [Hafner and Markoff 1995, p- 321].
Up until 1995 there were not much more talk about buffer overflows, before it was
rediscovered and mention by Thomas Lopatic in a Bugtrac report on a vulnerability
in NCSA HTTPD 1.3 [Lopatic 1995]. In 1996 Eliav Levy, aka Aleph One, published
the paper Smashing the stack for fun and profit in Phrack magazine number 49.
This was a step-by-step tutorial on how to exploit stack buffer overflows, and the
exploitation of this vulnerability was from now often called ”smashing the stack”
[One 1996]. Today, this paper is still considered one of the ultimate sources for
general information about stack buffer overflows. This paper will discuss more
details of buffer overflows, both stack and heap, in Chapter 3. Smashing the stack
attacks was first tried mitigated with the help of a so called canary value before the
saved return address on the stack. When the function returns, the canary is checked
if it matches the original value [Harris et al. 201]. Attackers found ways of writing
arbitrary data into the buffer, without overwriting the canary, by overwriting other
pointers [Snow et al. 2013, p- 1] [Hoglund and McGraw 2004, p- 361-364]. This
led to other mitigation techniques, namely the No eXecute-bit (NX-bit) in the x86
architecture and the Data Execution Protection (DEP), making it possible to mark
memory pages as non-executable, which in turn made all shellcode placed on the
stack non-executable and unusable. This was then defeated with a technique called
return-to-libc. libc is a system library containing basic functions which are shared,
and thereby it is possible for a program, or an exploit, to redirect its execution into
the library. The functions to use is much more restricted, than what is possible
with a executable stack [Erickson 2008, p- 376-377]. return-to-libc attacks was later
improved to return oriented programming or RoP, where it is not just possible to
call functions in shared libraries, single instructions, called gadgets, can be called
from both libraries and running processes. Once again the cat and mouse game is
on, and developers came up with the idea of randomizing the stack memory layout,
causing the attacker to not know where his shellcode is placed. This technique was
named Address Space Layout Randomization, or ASLR for short. But as always,
attackers find a way around new protection mechanisms, and this was also the
case with ASLR, as you will see later in this paper. To understand the reason
for using ASLR and how it works, it is first important to understand details of
the different attacking methods ASLR is meant to protect against. This paper is
organized as follows. Section 1 is the introduction you now are reading. Section
2 describes why ASLR is needed and details on how buffer overflows in the stack
and heap is done. Section 3 describes ASLR in general, its history and how it was
originally implemented, together with some general weaknesses, vulnerabilities and
improvements. Section 4 describes how ASLR is implemented in the most used
operating systems, both for general computers and devices like smart phones and
tablets, both originally and today. Microsoft Windows will be discussed most, since
it is the most used operating system and easiest to find information about. Section
5 gives a conclusion of the paper.
2. RELATED WORK
Most computer security books describe the basic of buffer overflows and specifically
also stack overflow and in some degree heap overflows. Books like [Gollmann 2012]

3. Fighting buffer overflows withAddress Space Layout Randomization · 3
have a especially easy to read description. Also when it comes to books covering
ethical hacking and penetration testing, like for example [Harris et al. 201] and
[Erickson 2008], both the basic of the different overflows, and how to write exploits
to circumvent protection mechanisms is discussed. The ultimate paper on stack
overflows is the 1996 paper Smashing the stack for fun and profit by Eliav Levy
[One 1996]. When it comes to ASLR, not many books describe it in details. The
fundamentals are covered it many books, including the ones just mentioned. To get
in to the details of ASLR, it is necessary to dive deeper into the different imple-
mentations in different operating systems. The main source for information about
ASLR in Windows is the book Windows Internals, which in 2012 came in its 6th
edition covering Windows 7 and Windows Server 200R2 [Russinovich et al. 2012].
I guess it will not be long before the 7th edition covering Windows 8 and Server
2013, will be out. In these books most of the internals of the Windows operating
system is described in detail, including ASLR. ASLR, especially in Windows, is
also mentioned quite a lot on security conferences like Black Hat, both its inter-
nals [Johnson and Miller 2012] and how it is bypassed [Sotirov 2009]. ASLR in
Linux is amazingly little written about, except for the original paper about the
implementation of ASLR in the Pax project [ThePaxTeam 2001]. The best place
to look for information about ASLR in Linux is feature descriptions on the different
distributions, kernel history and source code. This is also true for Android, which
also is Linux, most of what is written about it is on official web sites of the Android
Project. When it comes to Apples OS X and iOS, which still relies a bit on security
by obscurity, very little about its protection mechanisms inner workings is known.
The best source for information about these, also about ASLR, is the books Mac
Hacker’s Handbook [Miller and Zovi 2009] and iOS Hacker’s Handbook [Miller and
Zovi 2012], both by amoung others Charlie Miller. These books, especially the
one about Mac, is quite outdated, so the best source for the newest information
about protection mechanisms in Apple’s operating systems are article in IT mag-
azines when new versions are released. There have also been some research into
ASLR improvements, which is described in papers like for example Just-in-time
code reuse: On the effectiveness of fine-grained address space layout randomization
from 2013 [Snow et al. 2013]. I have not been able to find any book, website, article
or paper that describes ASLR the way it is described in this paper, with both the
background for using ASLR, the history and how it is implemented in different
operating systems
3. THE REASONS FOR ASLR
Every process running on a computer system with a modern operating system is,
when it is started, assigned its own private address space in memory, its virtual
memory. This separates the process from the physical memory, and the translation
between virtual and physical memory addresses is done with the help of one or
more address translation tables [Wolthausen 2013]. Traditionally the base address
for the executables image, the stack, the heap and the libraries is placed on the same
addresses each time a process is started. This makes it possible for an adversary
to know where in memory the different areas are placed. Let us now take a look at
why this is bad.

4. Fighting buffer overflows withAddress Space Layout Randomization · 4
3.1 Buffer overflow
”Buffer overflows are memory corruption vulnerabilities” [Klein 2011] that very
often occur in programming languages like C and C++, since memory management
is left to the programmer, i.e. it is up to the programmer to manage tasks like
boundary checking of variables [Wolthausen 2013]. When a program is executed,
variables are allocated to buffers, and if the boundary checking of the data going
in to the variable is not properly done, the buffer will overflow if the value assigned
to the variable exceed the size of the allocated size, and you have a Buffer overflow
[Gollmann 2012]. According to the RSOS (Research in Secure Operating Systems)
study conducted in the 1970s, vulnerabilities like buffer overflow is placed in the
family of ”incomplete parameter validation” [Bishop 2002, p- 664-668], since this
vulnerability occurs because of the lack of input validation or filtering. In intype-
safe, or memory-safe, programming languages like Java this problem does not exist,
since the memory management is done by the Java Virtual machine (JVM). The
only case a buffer overflow can occur in Java is if there is a vulnerability in them
JVM itself, since this in most cases are written in C++ [Gollmann 2012]. The main
reason for getting buffer overflows in a program is the use of unsafe string handling
functions like strcopy(), sprintf() and gets(). Here is an example using strcpy():
char ∗ strncpy ( char ∗Dst , const char ∗ Src )
There is no boundary checking of the variable *Src before it is copied into *Dst.
If *Src have a bigger size than *Dst, a buffer overflow will occur. To help with the
problem in this example, a safer function like strncpy() can be used, since this have
a third input size t which tells the ”Maximum number of characters to be copied
from source” [cplusplus.com 2013] .:
char ∗ strncpy ( char ∗Dst , const char ∗Src , s i z e t count )
Using the safer functions, doesn´t ”automacigally” mitigate the problem of buffer
overflows, the programmer still need to make sure that the maximal size of the
destination variable is big enough [Gollmann 2012]. One can always say that pro-
grammers should use only the more secure function to have less vulnerabilities in
their software, but programmers use the knowledge they’ve obtained trough train-
ing in universities etc., and in for example the book ”Object-oriented programming
in C++” by Robert Lafore from 2001, which is used in C and C++ courses in mul-
tiple universities, strncpy() is not mentioned at all in its 1012 pages, only strcpy()
[Lafore 2002]. Why this is not mentioned is ”newer” books is strange, since already
in the second edition of the original book on the C language, ”The C programming
language 2nd edition” by Brian Kernighan and Dennis Ritchie (the creator of C)
from 1988, both strcpy() and strncpy() is mentioned. When hunting for buffer
overflows today, there is basically two kind of buffers an attacker can overwrite, the
Stack and the Heap [Klein 2011].
3.1.1 Stack overflow. The stack section in memory is used to keep track of calls
to functions and is growing from high to low addresses. The case that it is growing
from high to low is the reason that stack buffer overflows is possible [Harris et al.
201, p- 182]. When a program calls a function, for example void func(char * foo),

5. Fighting buffer overflows withAddress Space Layout Randomization · 5
the input variables to the function, the functions local variables, the return address1
and the saved frame pointer2
is pushed onto the stack. As it is shown in Figure 1,
the input variables to the function is placed on the top, then the return address,
the saved framed pointer, and at the last the local variables. When the function
is filling data in to its local variables, the values are getting assigned up in the
stack, towards the saved frame pointer and return address. Here is the base to
the problem of stack overflows, when more data are copied into the functions local
variables, the saved frame pointer and return address will be overwritten. In stack
overflows, the return address is the most important part, since this controls where
in memory the program shall return to when the function is finished. If nothing
wrong is done, the program will return to where it left before calling the function,
if the return address is overwritten with bogus data, the program will crash, and if
it is overwritten with another memory address, it will go there. So, if an attacker
places arbitrary code, so called shellcode3
, somewhere in memory, for example below
the overwritten return address, and places its address in the return address, the
program will return to his code and run it. This method is called the argv method,
since the shellcode is passed as an argument to the vulnerable function stored to the
stack. A down thing, for the attacker, is that this method requires an executable
stack, which protection mechanisms like DEP and NX-bit prevents. When these
mitigations techniques are in place, methods like return-to-libc, or return oriented
programming, can be used. This is a technique where the attacker calls system
libraries, and makes them do the dirty work, instead of placing his own shellcode
on the stack [Gollmann 2012]. Here the attacker can use system functions like for
example exec(), which will take a supplied system command and execute it for the
attacker.
A simple program vulnerable to stack overflow is shown in below. This program
takes an argument, send this to the function func() which puts the content of the
received variable into its local variable foo. The function then copies the content
of foo into bar, which is of size 10, using strcpy() and then print the content of bar.
An argument bigger than 10 characters will cause a buffer overflow.
void func ( char ∗ foo ){
char bar [ 1 0 ] ;
strcpy ( bar , foo ) ;
p r i n t f bar ;
}
int main ( int argc , char ∗argv [ ] ) {
p r i n t f func ( argv [ 1 ] ) ;
return 0;
}
A technique to mitigate the problem with both the argv method and return-to-
libc is ASLR, since this randomizes the memory layout, so the attacker will not
1Extended Instruction pointer (EIP)
2Extended Base Pointer (EBP)
3Shellcode is a short code used as payload when exploiting a vulnerability in a computer system

6. Fighting buffer overflows withAddress Space Layout Randomization · 6
Fig. 1. A typical stack before and after a stack overflow has occurred
know either where is shellcode is placed, or where the system libraries are located.
But as we will see later, the world is not perfect and neither is ASLR, so multiple
ways of bypassing this have been discovered.
3.1.2 Heap overflows. The heap section in memory stores dynamically allocated
variables, and is growing from low to high addresses. In the programming language
C, the allocation of memory is done with the malloc() function, and deallocation
is done with free() [Harris et al. 201, p- 182]. When a process calls the allocation
function, memory is reserved in the virtual address space, and an address is returned
to the process so it knows where the heap starts [Lindner 2006]. The memory space
that now is reserved can be used just the way the programmer have decided, and
freed when there is no more use for it. A typical example of what the heap is
used for is for storing larger data structures like for example files read into memory
by the process that owns the heap. That said, heap overflows are usually just as
dangerous as stack overflows. By overflowing the heap, important user data can
be overwritten, but that is not the worst thing. Heap overflows can also be used
to overwrite function pointers that may be living in memory, and by that redirect
the control flow of the program to malicious code. An example of a code that is
vulnerable to heap buffer overflow is shown below. The programs takes an argument
as input and copies it into a 256Byte long buffer allocated by malloc() on the heap.
If the argument is longer than 256Bytes, we have a heap buffer overflow [OWASP
2009].
int main ( int argc , char ∗argv [ ] ) {
char ∗ foobar ;
buf = ( char ∗) malloc (256);
strcpy ( foobar , argv [ 1 ] ) ;
}
Heap overflow are also tried mitigated using ASLR.

7. Fighting buffer overflows withAddress Space Layout Randomization · 7
4. INTRODUCING ASLR
The term Address Space layout Randomization, was first used in July 2001 in the
PaX4
project, which is a patch for the Linux kernel implementing least privilege
protection for memory pages [ThePaxTeam 2001]. Although the PaX project was
the first using the term ASLR, a limited form of stack randomization was used by
the Israeli company Memco Software Ltd as early as in 1997, as a part of the SeOS
Access Control product. This was described in US patent 5949973A, under the title
Method of relocating the stack in a computer system for preventing overrate by an
exploit program [Yarom 1999].
ASLR is used to randomize the virtual memory layout each time a process starts,
and by this preventing attackers from performing a reliable jump in memory. [Klein
2011] describe ASLR like this: ”ASLR randomizes the location of key areas of a
process space (usually the base address of the executable, the position of the stack,
the heap, the libraries, and others) to prevent an exploit writer from predicting
target addresses”.
This introduction of randomness, or entropy [Erickson 2008, p- 379], will make
good old stack and heap buffer flow attacks fail with a high probability, and al-
low them to be easily detected, since failure in exploitation most likely will crash
the process. In some situations, the crash is just as serious as a successfully com-
promisation, for example in some control systems [Digitalbond 2013]. Although
ASLR sounds very secure, multiple ways of bypassing ASLR is known and it alone
is often not enough to stop an attacker. If the virtual memory area the random-
ization occurs is to small, to defeat ASLR, an attacker simply just need to guess,
by brute forcing, the position of all the areas he is attacking. For areas like the
stack and the heap, this can be done with the help of a so called NOP-slide, and
simply just ”slide” into the correct address space. Another possibility is to brute
force the memory areas, and by this find the correct one. This was very easy on
early ASLR implementations, since they randomized only on a handful of address
locations [Digitalbond 2013] [Microsoft 2010a] .
Today, the amount of virtual memory area space to randomised have increased
exponentially, especially in Windows 8, and brute force will simply take to much
time. More details about this when the different operating systems will be discussed
later.
The simplest way of bypassing ASLR is often to return into modules without
ASLR enabled [Harris et al. 201, p- 324]. For example the Dropbox application for
Windows in September 2013 [Sutherland 2013].
Although ASLR makes it harder to exploit existing vulnerabilities, it is not a
replacement for insecure code. The purpose of ASLR is to protect against vulner-
abilities that have not been fixed [M¨uller 2008].
For a operating system to have a true ASLR implementation, it must have ran-
domization of all libraries, executables, the stack and the heap [Miller and Zovi
2009].
4Page EXec

8. Fighting buffer overflows withAddress Space Layout Randomization · 8
5. IMPROVEMENTS
In most situations when ASLR is ”improved” in an operating system, it is basically
doing the same thing as before, only better. An example is improvements in ASLR
from Windows 7 to Windows 8, which basically just is an increase in the memory
space used in the randomisation, and randomisation of more areas in memory, for
example by forcing ASLR on applications compiled without ASLR support. Since
attackers in many cases is capable of bypassing ASLR, it is most effective to use it
in combination with DEP, since there is a very few exploit to this date that try to
bypass the joining forces of DEP and ASLR [Microsoft 2010a].
6. IMPLEMENTATIONS IN POPULAR OPERATIVE SYSTEMS
There is a big difference in both when ASLR was implemented, and how it is
implemented in different operating systems. Multiple operating systems have been
advertising with having ASLR through history, but this is often just partial. Today
the most used operating systems is Microsoft Windows, Apple OS X, Android and
Apple iOS. This section will therefore describe the ASLR implementation in each
of these separately. With an extra focus on Windows.
6.1 Microsoft Windows
ASLR was introduced in Windows Vista Beta 2 in June 2006, and is present in
all subsequent Windows versions[M¨uller 2008], both client and server versions. To
understand how ASLR works in Windows it is necesarry to know the memory layout
for the user address space. User address space is divided into multiple regions of
memory. Simplified it can be described like this: From the top we have the image
of executables and DLLs, then the heap of the process, and at the bottom the stack
for each thread. This can be seen in Figure 2 [Russinovich et al. 2012].
For a program to support ASLR, all its loaded components also must support
ASLR. For example if the program foo.exe loads bar.dll and sys.dll, all three of
them must support ASLR. If only one of them is compiled without ASLR support,
ASLR is disabled by the entire process.
From Windows Vista all system DLLs and EXEs is randomized, but applications
from third party developers, both EXEs and DLLs, need to be compiled using the
/DYNAMICBASE linker flag in Microsoft Visual Studio [Microsoft 2010b] [Russi-
novich et al. 2012]. This is in many cases not done, and they have predictable mem-
ory addresses. For application without ASLR support a very handy tool called En-
hanced Mitigation Experience Toolkit (EMET) can be used [Microsoft 2011] [Krebs
2012]. This can be used to force ASLR, and by that forces all non-ASLR images to
into using randomized memory addresses in application not supporting it out of the
box. Windows 8 and Windows 7 with KB2639308 installed actually introduced the
possibility to Force ASLR for all application, without the use of tools like EMET.
Figure 3 and 4 shows the virtual memory area without and with EMET, or another
way of forcing ASLR for all applications.
Although both Vista and Server 2008 had ASLR enabled for all system exe-
cutables, it was, together with DEP, disabled for Internet Explorer 7, because of
compatibility problems with many common applications. In IE8, ASLR was en-
abled by default, but attackers then could call other components not protected by

9. Fighting buffer overflows withAddress Space Layout Randomization · 9
Fig. 2. The memory layout for a typical process in Windows 7 without ASLR [Russinovich et al.
2012]
ASLR, and use heap-spraying to get their shellcode into non-ASLR and non-NX
memory areas [Microsoft 2008]. In addition to not having ASLR enabled for all
parts of memory, there were also quite a bit of other vulnerabilities with the ASLR
implementation in Vista and 7. For example predictable memory areas, because
of low entropy (few bits for randomization), and information disclosures which is
also called memory leakage. All of these vulnerabilities have been tried resolved in
Windows 8, which now calls ASLR for HiASLR because of its high entropy, which
is described a bit later.
If the application is supporting ASLR, their placement in memory will be ran-
domized for each time the process starts. The way the randomization is done varies
for the different memory areas. The number of bits used in the randomization for
Windows 7 and Windows 8 is shown in Figure 5.
For example in Windows 7 the EXEs and DLLs had 8 bit of entropy, which means
it is 256 possible base addresses within the range of 16MB of image addresses in the
PE header. The 8 bits are the same for both 32-bit and 64-bit in Windows 7. In
Windows 8 the number is the same for the 32-bit version, but for 64-bit EXE files
get 17 bits and DLLs 19, if the computer have more than 4GB RAM. In Windows
7, the stack have 14 bits of entropy, which gives a total of 16384 possible base
addresses. An interesting thing here is that Symantec did some experiements, and

10. Fighting buffer overflows withAddress Space Layout Randomization · 10
Fig. 3. The memory layout in Windows without forcing ASLR for processes compiled without it
[Whitehous 2007]
Fig. 4. The memory layout in Windows when forcing ASLR for processes compiled without it
[Whitehous 2007]

11. Fighting buffer overflows withAddress Space Layout Randomization · 11
Fig. 5. The number of bits used for the different memory areas in Windows 7 and 8 [Russinovich
et al. 2012]
found that in reality, the number where not so high. Their experiment showed that
the stack only got 8568 different base addresses, that is only 52% of what is should
be [Whitehous 2008] [Whitehous 2007]. In Windows 8 the entropy for the stack
have increased to 17 bits, which give a total of 131072 different base addresses. No
research was found to support if this is a fact in reality too. If Windows 8 is running
with High entropy (HE) enabled, the stack gets a entropy of stunningly 33 bits!
ASLR is not only used in the User space, but also the Kernel space, although
there isn’t much information available on the subject. According to [Russinovich
et al. 2012] Windows 8 have 64 possible base addresses for 32-bit drivers, and 256
for 64-bit drivers.
To check if a process is running under the protection of ASLR, one can use a
program called Process explorer, which is a part of the good old Sysinternal Suite
[Microsoft 2013]. Many very common applications do not use this protection ASLR,
for example Putty and Dropbox [Sutherland 2013]. A screenshot of Process Ex-
plorer showing that the Dropbox process is not using ASLR is shown in 6, although
the screenshot is taken from Windows 8.1, which should force ASLR, but apparently
not always.
Example of other ASLR statuses seen in Process explorer is shown below:
svchost . exe − Enabled
explore . exe − High Entropy , Force Relocate
cmd . exe − High Entropy
6.2 Apple OS X
ASLR first appeared in OS X 10.5 Leopard in 2007, but according to the world
famous Mac hacker, Charlie Miller, this can hardly be called ASLR since it only
randomizes some of the libraries. True ASLR requires, as mentioned, randomization
of all libraries, executables, the stack and the heap [Miller and Zovi 2009]. In 2009

12. Fighting buffer overflows withAddress Space Layout Randomization · 12
Fig. 6. Process explorer showing that Dropbox is not using ASLR
OS X 10.6 Snow Leopard was released, but the world saw no improvements in the
ASLR implementation, which made the biggest competitor Windows Vista, and
the then newly released Windows 7 more secure. Even though the lack of good
ASLR implementation, there was still a perception that the security in OS X was
good. This relied mostly on the fact that OS X still had a very little marked share
compared to Windows, and the security relied much on ”security by obscurity”
[Softpedia 2009]. With the release of OS X 10.7 Lion in 2011, a lot was changed.
OS X now had a full implementation of ASLR, and was now by many considered to
have better security than Windows 7 [Softpedia 2011]. Up until the release of OS
X 10.8 Mountain Lion in 2012, ASLR was only implemented for the user space in
memory, but from now on the kernel space was also included, which made it harder
to exploit the low-level functions. ASLR in the OS X kernel was improved in OS
X 10.9 Mavericks, which was released in 2013 [Apple 2013]. Most of the technical
details of how ASLR is implemented in OS X is not publicly known, and therefore
not discussed in this paper. Apple is still denying Saltzer and Schroeders design
principle on open design from 1975 [Saltzer and Schroeder 1975], and in many ways

13. Fighting buffer overflows withAddress Space Layout Randomization · 13
depend on ”security by obscurity”.
6.3 Linux
In June 2005 ASLR was implemented and enabled by default in Linux Kernel 2.6.12
[M¨uller 2008], but had been available with the Pax patch from 2001 [ThePaxTeam
2001]. The first implementation did not have randomization of all memory areas,
only areas like the stack and shared libraries [Kernelnewbies 2005]. There were also
several complains about the first implementation, since the randomisation of the
stack only occurred over a 64KB area, and the shared libraries within 1MB. The
authors of the implementation excused this by saying that the area of randomisation
was going to increase in later versions [corbet 2005]. Full ASLR support and larger
memory areas for randomisation came in later kernel versions, but the author of this
paper have not been able to find out in which version and how big the entropy is.
According to [Ubuntu 2013] Ubuntu had ASLR implemented on all memory areas,
including the kernel memory space, in version 8.10, which came out in October
2010. A big difference between ASLR in Windows and Linux is that in Windows,
before 8 and without EMET, you have to enable ASLR for each application, in
Linux is that you can enable or disable ASLR globally with just changing a number
in the configuration file /proc/sys/kernel/randomize va space [Carter 2010]. The
three different numbers are shown below with a description.
0 − ASLR disabled
1 − Shared l i b r a r i e s and PIE b i n a r i e s are randomized
( conservative )
2 − Adds randomizing the s t a r t of the brk area ,
along with conservative s e t t i n g s ( f u l l )
Prior to Ubuntu 8.10, the number was default 1, but then changed to 2 for all
later releases [Ubuntu 2013].
The use of this configuration file, makes it possible with a very easy example of
how ASLR is working on shared libraries, using the command ldd in Linux. This
command print shared library dependencies and their memory address. With full
ASLR enabled (2), it is shown below that the addresses of all shared libraries are
changing everytime they are checked:
john@ubuntu :/ bin$ ldd l s
linux−vdso . so .1 => (0 x00007fffc4307000 )
l i b s e l i n u x . so .1 => / l i b /x86 64−linux−gnu/ l i b s e l i n u x . so .1 (0
x00007f4d6051c000 )
l i b r t . so .1 => / l i b /x86 64−linux−gnu/ l i b r t . so .1 (0
x00007f4d60314000 )
l i b a c l . so .1 => / l i b /x86 64−linux−gnu/ l i b a c l . so .1 (0
x00007f4d6010b000 )
l i b c . so .6 => / l i b /x86 64−linux−gnu/ l i b c . so .6 (0
x00007f4d5fd43000 )
l i b p c r e . so .3 => / l i b /x86 64−linux−gnu/ l i b p c r e . so .3 (0
x00007f4d5fb04000 )
libpthread . so .0 => / l i b /x86 64−linux−gnu/ libpthread . so .0 (0
x00007f4d5f8e6000 )

14. Fighting buffer overflows withAddress Space Layout Randomization · 14
l i b d l . so .2 => / l i b /x86 64−linux−gnu/ l i b d l . so .2 (0
x00007f4d5f6e2000 )
/ lib64 /ld−linux−x86 −64. so .2 (0 x00007f4d6075b000 )
l i b a t t r . so .1 => / l i b /x86 64−linux−gnu/ l i b a t t r . so .1 (0
x00007f4d5f4dd000 )
john@ubuntu :/ bin$ ldd l s
linux−vdso . so .1 => (0 x00007fff99bfe000 )
l i b s e l i n u x . so .1 => / l i b /x86 64−linux−gnu/ l i b s e l i n u x . so .1 (0
x00007fd728c4f000 )
l i b r t . so .1 => / l i b /x86 64−linux−gnu/ l i b r t . so .1 (0
x00007fd728a47000 )
l i b a c l . so .1 => / l i b /x86 64−linux−gnu/ l i b a c l . so .1 (0
x00007fd72883e000 )
l i b c . so .6 => / l i b /x86 64−linux−gnu/ l i b c . so .6 (0
x00007fd728476000 )
l i b p c r e . so .3 => / l i b /x86 64−linux−gnu/ l i b p c r e . so .3 (0
x00007fd728237000 )
libpthread . so .0 => / l i b /x86 64−linux−gnu/ libpthread . so .0 (0
x00007fd728019000 )
l i b d l . so .2 => / l i b /x86 64−linux−gnu/ l i b d l . so .2 (0
x00007fd727e15000 )
/ lib64 /ld−linux−x86 −64. so .2 (0 x00007fd728e8e000 )
l i b a t t r . so .1 => / l i b /x86 64−linux−gnu/ l i b a t t r . so .1 (0
x00007fd727c10000 )
john@ubuntu :/ bin$ ldd l s
linux−vdso . so .1 => (0 x00007fff3a97c000 )
l i b s e l i n u x . so .1 => / l i b /x86 64−linux−gnu/ l i b s e l i n u x . so .1 (0
x00007fe563dae000 )
l i b r t . so .1 => / l i b /x86 64−linux−gnu/ l i b r t . so .1 (0
x00007fe563ba6000 )
l i b a c l . so .1 => / l i b /x86 64−linux−gnu/ l i b a c l . so .1 (0
x00007fe56399d000 )
l i b c . so .6 => / l i b /x86 64−linux−gnu/ l i b c . so .6 (0
x00007fe5635d5000 )
l i b p c r e . so .3 => / l i b /x86 64−linux−gnu/ l i b p c r e . so .3 (0
x00007fe563396000 )
libpthread . so .0 => / l i b /x86 64−linux−gnu/ libpthread . so .0 (0
x00007fe563178000 )
l i b d l . so .2 => / l i b /x86 64−linux−gnu/ l i b d l . so .2 (0
x00007fe562f74000 )
/ lib64 /ld−linux−x86 −64. so .2 (0 x00007fe563fed000 )
l i b a t t r . so .1 => / l i b /x86 64−linux−gnu/ l i b a t t r . so .1 (0
x00007fe562d6f000 )
With ASLR disabled (0), the below result show that the addresses to shared
libraries remain the same during three checks with ldd:
john@ubuntu :/ bin$ ldd l s

15. Fighting buffer overflows withAddress Space Layout Randomization · 15
linux−vdso . so .1 => (0 x 0 0 0 0 7 f f f f 7 f f d 0 0 0 )
l i b s e l i n u x . so .1 => / l i b /x86 64−linux−gnu/ l i b s e l i n u x . so .1 (0
x00007ffff7dbe000 )
l i b r t . so .1 => / l i b /x86 64−linux−gnu/ l i b r t . so .1 (0
x00007ffff7bb6000 )
l i b a c l . so .1 => / l i b /x86 64−linux−gnu/ l i b a c l . so .1 (0
x00007ffff79ad000 )
l i b c . so .6 => / l i b /x86 64−linux−gnu/ l i b c . so .6 (0
x00007ffff75e5000 )
l i b p c r e . so .3 => / l i b /x86 64−linux−gnu/ l i b p c r e . so .3 (0
x00007ffff73a6000 )
libpthread . so .0 => / l i b /x86 64−linux−gnu/ libpthread . so .0 (0
x00007ffff7188000 )
l i b d l . so .2 => / l i b /x86 64−linux−gnu/ l i b d l . so .2 (0
x00007ffff6f84000 )
/ lib64 /ld−linux−x86 −64. so .2 (0 x0000555555554000 )
l i b a t t r . so .1 => / l i b /x86 64−linux−gnu/ l i b a t t r . so .1 (0
x00007ffff6d7f000 )
john@ubuntu :/ bin$ ldd l s
linux−vdso . so .1 => (0 x 0 0 0 0 7 f f f f 7 f f d 0 0 0 )
l i b s e l i n u x . so .1 => / l i b /x86 64−linux−gnu/ l i b s e l i n u x . so .1 (0
x00007ffff7dbe000 )
l i b r t . so .1 => / l i b /x86 64−linux−gnu/ l i b r t . so .1 (0
x00007ffff7bb6000 )
l i b a c l . so .1 => / l i b /x86 64−linux−gnu/ l i b a c l . so .1 (0
x00007ffff79ad000 )
l i b c . so .6 => / l i b /x86 64−linux−gnu/ l i b c . so .6 (0
x00007ffff75e5000 )
l i b p c r e . so .3 => / l i b /x86 64−linux−gnu/ l i b p c r e . so .3 (0
x00007ffff73a6000 )
libpthread . so .0 => / l i b /x86 64−linux−gnu/ libpthread . so .0 (0
x00007ffff7188000 )
l i b d l . so .2 => / l i b /x86 64−linux−gnu/ l i b d l . so .2 (0
x00007ffff6f84000 )
/ lib64 /ld−linux−x86 −64. so .2 (0 x0000555555554000 )
l i b a t t r . so .1 => / l i b /x86 64−linux−gnu/ l i b a t t r . so .1 (0
x00007ffff6d7f000 )
john@ubuntu :/ bin$ ldd l s
linux−vdso . so .1 => (0 x 0 0 0 0 7 f f f f 7 f f d 0 0 0 )
l i b s e l i n u x . so .1 => / l i b /x86 64−linux−gnu/ l i b s e l i n u x . so .1 (0
x00007ffff7dbe000 )
l i b r t . so .1 => / l i b /x86 64−linux−gnu/ l i b r t . so .1 (0
x00007ffff7bb6000 )
l i b a c l . so .1 => / l i b /x86 64−linux−gnu/ l i b a c l . so .1 (0
x00007ffff79ad000 )
l i b c . so .6 => / l i b /x86 64−linux−gnu/ l i b c . so .6 (0
x00007ffff75e5000 )

16. Fighting buffer overflows withAddress Space Layout Randomization · 16
l i b p c r e . so .3 => / l i b /x86 64−linux−gnu/ l i b p c r e . so .3 (0
x00007ffff73a6000 )
libpthread . so .0 => / l i b /x86 64−linux−gnu/ libpthread . so .0 (0
x00007ffff7188000 )
l i b d l . so .2 => / l i b /x86 64−linux−gnu/ l i b d l . so .2 (0
x00007ffff6f84000 )
/ lib64 /ld−linux−x86 −64. so .2 (0 x0000555555554000 )
l i b a t t r . so .1 => / l i b /x86 64−linux−gnu/ l i b a t t r . so .1 (0
x00007ffff6d7f000 )
6.4 Android
In the Android operating system ASLR was introduced in version 4.0 Ice Cream
Sandwich in 2010, but only partial. Only a few certain memory areas was ran-
domised, and attacks like return oriented programming was not prevented, since
the hole executables image could be used as a source for gadgets.
It was not until version 4.1 Jelly Bean in 2012 there was a full implementa-
tion of ASLR, but only in the user memory space. ASLR in kernel space is
something Google is working with for future releases [AndroidOpenSourceProject
2013] [Threatpost 2012]. Since Android is Linux, it is possible to check the file
/proc/sys/kernel/randomize va space again, to see how ASLR is implemented. In
Ice Cream Sandwich, the number in the file was 1, but from Jelly Bean it was
changed to 2 The number of bits used in the randomisation entropy in Android is
unknown, but since Android at the moment is a 32 bit operating system, the bits
used for entropy is relatively low, as seen when we discussed ASLR in Windows.
How the memory base address of a executable image in Jelly bean is changed each
time the executable is run is shown in Figure 7.
Fig. 7. Randomisation of executable image base memory addresses [Threatpost 2012]
6.5 iOS
In the first versions of iOS, the were very few security protection mechanisms in
place. Although iOS was released in 2007, ASLR first appeared in iOS 4.3 in March
2011, but before this it was available to Jailbroken iOS devices using an extension
called Antid0te by Stefan Esser [Esser 2012]. For Jailbreaking, the introduction of
ASLR was no show stopper, and jailbreakme.com soon had support for iOS up to
4.3.3. This was possible because a serious vulnerability made it possible to both
read and write from memory. This in turn made it possible for an exploit to read

17. Fighting buffer overflows withAddress Space Layout Randomization · 17
the memory address of some nearby pointers, and then get control of the process
by writing shellcode to memory and execute it [Miller and Zovi 2012]. Up until
iOS 6, iOS only had ASLR in the user space of memory, but from here on they also
implemented kernel space randomisation [Threatpost 2012]. The same goes with
iOS as with Android, the number of bits used for entropy is unknown, but since it
is a 32 bit operating system the number needs to be relatively low, which causes
the ASLR implementation to be relatively weak. Not much more is known about
ASLR in iOS, at least not information that is available to the author of this paper.
7. CONCLUSION
Since there apparently is no patch for human stupidity, not even the programmers
stupidity, buffer overflow is still a problem, and because of this the developers of
operating systems need to build in protection mechanisms like for example Data
Execution Prevention and Address Space Layout Randomization. All of the most
used operating systems today have ASLR built in, but the road to this have been
long. Both Linux, Windows, OS X, Android and iOS, were first released without
ASLR support. Linux was first out, in 2005, but already from 2001 ASLR was
available with the use of the Pax patch. In 2006 and 2007, OS X and Windows was
released with ASLR support, but only partial. This have been improved for both of
them up until OS X 10.9 and Windows 8.1. iOS and Android is the newest of today’s
most used operating systems, with ASLR support from 2011 and 2012, though not
a full implementation at first. iOS and Android, together with OS X, was the most
difficult operating systems to find information about, especially on how ASLR was
implemented. The biggest difference from the early ASLR implementations, to the
ones today is that randomisation is done in a much bigger virtual memory area,
and that ASLR now is implemented for more parts of the operating system. Still
vulnerabilities is being exploited, both by bypassing ASLR and by using modules
without ASLR support. So there is still improvements to be made. So, what will
the future bring, improvements to ASLR, or will developers come up with other,
and better, protection mechanisms?
REFERENCES
Anderson, J. P. 1972. Computer security technology planning study. volume 2. Tech. rep., DTIC
Document.
Anderson, R. 2008. Security engineering, 2nd edition. Wiley.
AndroidOpenSourceProject. 2013. Android security overview.
http://source.android.com/devices/tech/security/index.html. Accessed : 26.nov.2013.
Apple. 2013. Os x mavericks: Core technologies overview.
Bishop, M. 2002. Computer Security: Art and Science. Addison-Wesley Professional.
Carter, E. 2010. How was this executable built. http://blogs.cisco.com/security/how was this executable built/.
Accessed : 26.nov.2013.
corbet. 2005. Address space randomization in 2.6. http://lwn.net/Articles/121845/. Accessed :
16.dec.2013.
cplusplus.com. 2013. function: strncpy. http://www.cplusplus.com/reference/cstring/strncpy/.
Accessed : 28.nov.2013.
Digitalbond. 2013. Address space layout randomization (aslr).
http://www.digitalbond.com/scadapedia/security-controls/address-space-layout-
randomization-aslr/. Accessed : 15.dec.2013.
Erickson, J. 2008. Hacking: The art of exploitation. No Starch Press.

18. Fighting buffer overflows withAddress Space Layout Randomization · 18
Esser, S. 2012. Adding aslr to jailbroken iphones. SektionEins.
Gollmann, D. 2012. Computer security. Wiley.
Hafner, K. and Markoff, J. 1995. Cyberpunk: Outlaws and Hackers on the Computer Frontier,
Revised. SimonandSchuster. com.
Harris, S., Harper, A., Eagle, C., and Ness, J. 201. Gray hat hacking: the ethical hacker’s
handbookm 3rd edition. McGraw-Hill/Osborne.
Hoglund, G. and McGraw, G. 2004. Exploiting Software: How to break code. Pearson Education
India.
Johnson, K. and Miller, M. 2012. Exploit mitigation improvements in windows 8. Black Hat.
Kernelnewbies. 2005. Linux 2.6.12. http://kernelnewbies.org/Linux 2 6 12. Accessed :
16.dec.2013.
Klein, T. 2011. A bug hunter’s diary. No Starch Press.
Krebs, B. 2012. Windows security 101: Emet 4.0. http://krebsonsecurity.com/tag/enhanced-
mitigation-experience-toolkit/. Accessed : 17.dec.2013.
Lafore, R. 2002. Object-oriented programming in C++. Sams.
Lindner, F. 2006. A heap of risk: Buffer overflows on the heap and how they are ex-
ploited. http://www.h-online.com/security/features/A-Heap-of-Risk-747161.html. Accessed :
04.dec.2013.
Lopatic, T. 1995. Vulnerability in ncsa httpd 1.3. http://web.archive.org/web/20070901222723/http://www.security-
express.com/archives/bugtraq/1995 1/0403.html. Accessed : 15.dec.2013.
Microsoft. 2008. Ms08-078 and the sdl. http://blogs.msdn.com/b/sdl/archive/2008/12/18/ms08-
078-and-the-sdl.aspx. Accessed : 17.dec.2013.
Microsoft. 2010a. On the effectiveness of dep and aslr.
http://blogs.technet.com/b/srd/archive/2010/12/08/on-the-effectiveness-of-dep-and-aslr.aspx.
Accessed : 03.dec.2013.
Microsoft. 2010b. Windows isv software security defenses. http://msdn.microsoft.com/en-
us/library/bb430720.aspx. Accessed : 17.dec.2013.
Microsoft. 2011. The enhanced mitigation experience toolkit.
http://support.microsoft.com/kb/2458544. Accessed : 17.dec.2013.
Microsoft. 2013. Process explorer v15.40. http://technet.microsoft.com/en-
us/sysinternals/bb896653.aspx. Accessed : 17.dec.2013.
Miller, C. and Zovi, D. 2009. The Mac Hacker’s Handbook. Wiley.
Miller, C. and Zovi, D. 2012. The iOS Hacker’s Handbook. Wiley.
M¨uller, T. 2008. Aslr smack & laugh reference. In Seminar on Advanced Exploitation Techniques.
One, A. 1996. Smashing the stack for fun and profit. Phrack 7, 49.
OWASP. 2009. Heap overflow. https://www.owasp.org/index.php/Heap overflow. Accessed :
04.dec.2013.
Russinovich, M. E., Solomon, D. A., and Ionescu, A. 2012. Windows R Internals, Part 2:
Covering Windows Server R 2008 R2 and Windows 7. O’Reilly Media, Inc.
Saltzer, J. H. and Schroeder, M. D. 1975. The protection of information in computer systems.
Proceedings of the IEEE 63, 9, 1278–1308.
Snow, K. Z., Monrose, F., Davi, L., Dmitrienko, A., Liebchen, C., and Sadeghi, A.-R. 2013.
Just-in-time code reuse: On the effectiveness of fine-grained address space layout randomization.
In IEEE Symposium on Security and Privacy.
Softpedia. 2009. Windows 7 bests snow leopard says mac hacker.
http://news.softpedia.com/news/Windows-7-Bests-Snow-Leopard-Says-Mac-Hacker-
121895.shtml. Accessed : 29.nov.2013.
Softpedia. 2011. Mac os x lion brings significant security improvements.
http://news.softpedia.com/news/Mac-OS-X-Lion-Brings-Significant-Security-Improvements-
212818.shtml. Accessed : 29.nov.2013.
Sotirov, A. 2009. Bypassing memory protections: The future of exploitation. In USENIX Secu-
rity.

19. Fighting buffer overflows withAddress Space Layout Randomization · 19
Sutherland, G. 2013. Installing dropbox? prepare to lose aslr.
http://codeinsecurity.wordpress.com/2013/09/09/installing-dropbox-prepare-to-lose-aslr/.
Accessed : 03.dec.2013.
ThePaxTeam. 2001. Aslr. http://pax.grsecurity.net/docs/aslr.txt.
Threatpost. 2012. Android 4.1 jelly bean includes full aslr implementation.
http://threatpost.com/android-41-jelly-bean-includes-full-aslr-implementation-071612. Ac-
cessed : 09.dec.2013.
Ubuntu. 2013. Security features. https://wiki.ubuntu.com/Security/Features. Accessed :
16.dec.2013.
Whitehous, O. 2007. Gs and aslr in windows vista. BlackHat.
Whitehous, O. 2008. An analysis of address space layout randomization on windows vista.
Wolthausen, S. 2013. Applied information security: Lecture slides.
Yarom, Y. 1999. Method of relocating the stack in a computer system for preventing overrate by
an exploit program. US Patent 5,949,973.