19
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,

Fighting buffer overflows with Address Space Layout Randomization

Embed Size (px)

Citation preview

Page 1: Fighting buffer overflows with Address Space Layout Randomization

Fighting buffer overflows with Address Space LayoutRandomization

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 anew 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 anadversary 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 ageneral 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 vulnerabilitiesto be exploited, and described academically [Anderson 1972, p. 61]. According to[Anderson 2008, p- 118], in 2008 half of the technical attacks reported by CERTbulletins and security mailing lists, were of some kind of buffer overflow. This mightexplain 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 inthe wild. Stack buffer overflows, and buffer overflows in general, is possible becauseof the lack of proper boundary checking of variables in applications, which causesmemory corruption. In stack buffer overflows this makes it possible to overwriteinformation on the stack, including the functions return address. By doing this theprogram 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 unfortunateoutbreak of the Morris worm. The worm spread by exploiting a stack buffer overflowvulnerability in the Unix service finger, in addition to some other vulnerabilities,

Page 2: Fighting buffer overflows with Address Space Layout Randomization

Fighting buffer overflows withAddress Space Layout Randomization · 2

and infected approximately 6000 computers, or about 10% of the total number ofcomputers 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 wasrediscovered and mention by Thomas Lopatic in a Bugtrac report on a vulnerabilityin NCSA HTTPD 1.3 [Lopatic 1995]. In 1996 Eliav Levy, aka Aleph One, publishedthe 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 theexploitation of this vulnerability was from now often called ”smashing the stack”[One 1996]. Today, this paper is still considered one of the ultimate sources forgeneral information about stack buffer overflows. This paper will discuss moredetails of buffer overflows, both stack and heap, in Chapter 3. Smashing the stackattacks was first tried mitigated with the help of a so called canary value before thesaved return address on the stack. When the function returns, the canary is checkedif it matches the original value [Harris et al. 201]. Attackers found ways of writingarbitrary data into the buffer, without overwriting the canary, by overwriting otherpointers [Snow et al. 2013, p- 1] [Hoglund and McGraw 2004, p- 361-364]. Thisled to other mitigation techniques, namely the No eXecute-bit (NX-bit) in the x86architecture and the Data Execution Protection (DEP), making it possible to markmemory pages as non-executable, which in turn made all shellcode placed on thestack non-executable and unusable. This was then defeated with a technique calledreturn-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 intothe library. The functions to use is much more restricted, than what is possiblewith a executable stack [Erickson 2008, p- 376-377]. return-to-libc attacks was laterimproved to return oriented programming or RoP, where it is not just possible tocall functions in shared libraries, single instructions, called gadgets, can be calledfrom both libraries and running processes. Once again the cat and mouse game ison, 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 wasnamed Address Space Layout Randomization, or ASLR for short. But as always,attackers find a way around new protection mechanisms, and this was also thecase with ASLR, as you will see later in this paper. To understand the reasonfor using ASLR and how it works, it is first important to understand details ofthe different attacking methods ASLR is meant to protect against. This paper isorganized as follows. Section 1 is the introduction you now are reading. Section2 describes why ASLR is needed and details on how buffer overflows in the stackand heap is done. Section 3 describes ASLR in general, its history and how it wasoriginally implemented, together with some general weaknesses, vulnerabilities andimprovements. Section 4 describes how ASLR is implemented in the most usedoperating systems, both for general computers and devices like smart phones andtablets, both originally and today. Microsoft Windows will be discussed most, sinceit is the most used operating system and easiest to find information about. Section5 gives a conclusion of the paper.

2. RELATED WORK

Most computer security books describe the basic of buffer overflows and specificallyalso stack overflow and in some degree heap overflows. Books like [Gollmann 2012]

Page 3: Fighting buffer overflows with Address Space Layout Randomization

Fighting buffer overflows withAddress Space Layout Randomization · 3

have a especially easy to read description. Also when it comes to books coveringethical 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 exploitsto circumvent protection mechanisms is discussed. The ultimate paper on stackoverflows 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. Thefundamentals are covered it many books, including the ones just mentioned. To getin 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 aboutASLR in Windows is the book Windows Internals, which in 2012 came in its 6thedition 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 Server2013, will be out. In these books most of the internals of the Windows operatingsystem is described in detail, including ASLR. ASLR, especially in Windows, isalso 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 inLinux is amazingly little written about, except for the original paper about theimplementation of ASLR in the Pax project [ThePaxTeam 2001]. The best placeto look for information about ASLR in Linux is feature descriptions on the differentdistributions, kernel history and source code. This is also true for Android, whichalso is Linux, most of what is written about it is on official web sites of the AndroidProject. When it comes to Apples OS X and iOS, which still relies a bit on securityby obscurity, very little about its protection mechanisms inner workings is known.The best source for information about these, also about ASLR, is the books MacHacker’s Handbook [Miller and Zovi 2009] and iOS Hacker’s Handbook [Miller andZovi 2012], both by amoung others Charlie Miller. These books, especially theone about Mac, is quite outdated, so the best source for the newest informationabout protection mechanisms in Apple’s operating systems are article in IT mag-azines when new versions are released. There have also been some research intoASLR improvements, which is described in papers like for example Just-in-timecode reuse: On the effectiveness of fine-grained address space layout randomizationfrom 2013 [Snow et al. 2013]. I have not been able to find any book, website, articleor paper that describes ASLR the way it is described in this paper, with both thebackground for using ASLR, the history and how it is implemented in differentoperating 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 virtualmemory. This separates the process from the physical memory, and the translationbetween virtual and physical memory addresses is done with the help of one ormore address translation tables [Wolthausen 2013]. Traditionally the base addressfor the executables image, the stack, the heap and the libraries is placed on the sameaddresses each time a process is started. This makes it possible for an adversaryto know where in memory the different areas are placed. Let us now take a look atwhy this is bad.

Page 4: Fighting buffer overflows with Address Space Layout Randomization

Fighting buffer overflows withAddress Space Layout Randomization · 4

3.1 Buffer overflow

”Buffer overflows are memory corruption vulnerabilities” [Klein 2011] that veryoften occur in programming languages like C and C++, since memory managementis left to the programmer, i.e. it is up to the programmer to manage tasks likeboundary checking of variables [Wolthausen 2013]. When a program is executed,variables are allocated to buffers, and if the boundary checking of the data goingin to the variable is not properly done, the buffer will overflow if the value assignedto 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 thefamily of ”incomplete parameter validation” [Bishop 2002, p- 664-668], since thisvulnerability 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). Theonly case a buffer overflow can occur in Java is if there is a vulnerability in themJVM itself, since this in most cases are written in C++ [Gollmann 2012]. The mainreason for getting buffer overflows in a program is the use of unsafe string handlingfunctions like strcopy(), sprintf() and gets(). Here is an example using strcpy():

char ∗ s trncpy ( 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 theproblem in this example, a safer function like strncpy() can be used, since this havea third input size t which tells the ”Maximum number of characters to be copiedfrom source” [cplusplus.com 2013] .:

char ∗ s trncpy ( char ∗Dst , const char ∗Src , s i z e t count )

Using the safer functions, doesnt ”automacigally” mitigate the problem of bufferoverflows, the programmer still need to make sure that the maximal size of thedestination variable is big enough [Gollmann 2012]. One can always say that pro-grammers should use only the more secure function to have less vulnerabilities intheir software, but programmers use the knowledge they’ve obtained trough train-ing in universities etc., and in for example the book ”Object-oriented programmingin 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 alreadyin the second edition of the original book on the C language, ”The C programminglanguage 2nd edition” by Brian Kernighan and Dennis Ritchie (the creator of C)from 1988, both strcpy() and strncpy() is mentioned. When hunting for bufferoverflows today, there is basically two kind of buffers an attacker can overwrite, theStack and the Heap [Klein 2011].

3.1.1 Stack overflow. The stack section in memory is used to keep track of callsto functions and is growing from high to low addresses. The case that it is growingfrom 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),

Page 5: Fighting buffer overflows with Address Space Layout Randomization

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 functionis filling data in to its local variables, the values are getting assigned up in thestack, towards the saved frame pointer and return address. Here is the base tothe problem of stack overflows, when more data are copied into the functions localvariables, the saved frame pointer and return address will be overwritten. In stackoverflows, the return address is the most important part, since this controls wherein memory the program shall return to when the function is finished. If nothingwrong 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 ifit is overwritten with another memory address, it will go there. So, if an attackerplaces arbitrary code, so called shellcode3, somewhere in memory, for example belowthe overwritten return address, and places its address in the return address, theprogram 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 thestack. A down thing, for the attacker, is that this method requires an executablestack, which protection mechanisms like DEP and NX-bit prevents. When thesemitigations techniques are in place, methods like return-to-libc, or return orientedprogramming, can be used. This is a technique where the attacker calls systemlibraries, and makes them do the dirty work, instead of placing his own shellcodeon the stack [Gollmann 2012]. Here the attacker can use system functions like forexample exec(), which will take a supplied system command and execute it for theattacker.

A simple program vulnerable to stack overflow is shown in below. This programtakes an argument, send this to the function func() which puts the content of thereceived variable into its local variable foo. The function then copies the contentof 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 ∗ f oo ){char bar [ 1 0 ] ;s t r cpy ( bar , foo ) ;p r i n t f bar ;

}

i n t main ( i n t argc , char ∗argv [ ] ) {p r i n t f func ( argv [ 1 ] ) ;r e turn 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

Page 6: Fighting buffer overflows with Address Space Layout Randomization

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 multipleways of bypassing this have been discovered.

3.1.2 Heap overflows. The heap section in memory stores dynamically allocatedvariables, and is growing from low to high addresses. In the programming languageC, the allocation of memory is done with the malloc() function, and deallocationis done with free() [Harris et al. 201, p- 182]. When a process calls the allocationfunction, memory is reserved in the virtual address space, and an address is returnedto the process so it knows where the heap starts [Lindner 2006]. The memory spacethat now is reserved can be used just the way the programmer have decided, andfreed when there is no more use for it. A typical example of what the heap isused for is for storing larger data structures like for example files read into memoryby the process that owns the heap. That said, heap overflows are usually just asdangerous as stack overflows. By overflowing the heap, important user data canbe overwritten, but that is not the worst thing. Heap overflows can also be usedto overwrite function pointers that may be living in memory, and by that redirectthe control flow of the program to malicious code. An example of a code that isvulnerable to heap buffer overflow is shown below. The programs takes an argumentas 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 [OWASP2009].

i n t main ( i n t argc , char ∗argv [ ] ) {char ∗ f oobar ;buf = ( char ∗) mal loc ( 2 5 6 ) ;s t r cpy ( foobar , argv [ 1 ] ) ;

}

Heap overflow are also tried mitigated using ASLR.

Page 7: Fighting buffer overflows with Address Space Layout Randomization

Fighting buffer overflows withAddress Space Layout Randomization · 7

4. INTRODUCING ASLR

The term Address Space layout Randomization, was first used in July 2001 in thePaX4 project, which is a patch for the Linux kernel implementing least privilegeprotection for memory pages [ThePaxTeam 2001]. Although the PaX project wasthe first using the term ASLR, a limited form of stack randomization was used bythe Israeli company Memco Software Ltd as early as in 1997, as a part of the SeOSAccess Control product. This was described in US patent 5949973A, under the titleMethod of relocating the stack in a computer system for preventing overrate by anexploit 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. [Klein2011] describe ASLR like this: ”ASLR randomizes the location of key areas of aprocess 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 predictingtarget addresses”.

This introduction of randomness, or entropy [Erickson 2008, p- 379], will makegood 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 crashthe process. In some situations, the crash is just as serious as a successfully com-promisation, for example in some control systems [Digitalbond 2013]. AlthoughASLR sounds very secure, multiple ways of bypassing ASLR is known and it aloneis 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 thestack and the heap, this can be done with the help of a so called NOP-slide, andsimply just ”slide” into the correct address space. Another possibility is to bruteforce the memory areas, and by this find the correct one. This was very easy onearly ASLR implementations, since they randomized only on a handful of addresslocations [Digitalbond 2013] [Microsoft 2010a] .

Today, the amount of virtual memory area space to randomised have increasedexponentially, especially in Windows 8, and brute force will simply take to muchtime. More details about this when the different operating systems will be discussedlater.

The simplest way of bypassing ASLR is often to return into modules withoutASLR enabled [Harris et al. 201, p- 324]. For example the Dropbox application forWindows in September 2013 [Sutherland 2013].

Although ASLR makes it harder to exploit existing vulnerabilities, it is not areplacement for insecure code. The purpose of ASLR is to protect against vulner-abilities that have not been fixed [Muller 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 Zovi2009].

4Page EXec

Page 8: Fighting buffer overflows with Address Space Layout Randomization

Fighting buffer overflows withAddress Space Layout Randomization · 8

5. IMPROVEMENTS

In most situations when ASLR is ”improved” in an operating system, it is basicallydoing the same thing as before, only better. An example is improvements in ASLRfrom Windows 7 to Windows 8, which basically just is an increase in the memoryspace used in the randomisation, and randomisation of more areas in memory, forexample by forcing ASLR on applications compiled without ASLR support. Sinceattackers in many cases is capable of bypassing ASLR, it is most effective to use itin combination with DEP, since there is a very few exploit to this date that try tobypass 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 isimplemented in different operating systems. Multiple operating systems have beenadvertising with having ASLR through history, but this is often just partial. Todaythe most used operating systems is Microsoft Windows, Apple OS X, Android andApple iOS. This section will therefore describe the ASLR implementation in eachof 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 inall subsequent Windows versions[Muller 2008], both client and server versions. Tounderstand how ASLR works in Windows it is necesarry to know the memory layoutfor the user address space. User address space is divided into multiple regions ofmemory. Simplified it can be described like this: From the top we have the imageof executables and DLLs, then the heap of the process, and at the bottom the stackfor 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 supportASLR. For example if the program foo.exe loads bar.dll and sys.dll, all three ofthem 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 applicationsfrom 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] [Krebs2012]. This can be used to force ASLR, and by that forces all non-ASLR images tointo using randomized memory addresses in application not supporting it out of thebox. Windows 8 and Windows 7 with KB2639308 installed actually introduced thepossibility 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 anotherway 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 ofcompatibility problems with many common applications. In IE8, ASLR was en-abled by default, but attackers then could call other components not protected by

Page 9: Fighting buffer overflows with Address Space Layout Randomization

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-NXmemory areas [Microsoft 2008]. In addition to not having ASLR enabled for allparts of memory, there were also quite a bit of other vulnerabilities with the ASLRimplementation in Vista and 7. For example predictable memory areas, becauseof low entropy (few bits for randomization), and information disclosures which isalso called memory leakage. All of these vulnerabilities have been tried resolved inWindows 8, which now calls ASLR for HiASLR because of its high entropy, whichis 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 variesfor the different memory areas. The number of bits used in the randomization forWindows 7 and Windows 8 is shown in Figure 5.

For example in Windows 7 the EXEs and DLLs had 8 bit of entropy, which meansit is 256 possible base addresses within the range of 16MB of image addresses in thePE header. The 8 bits are the same for both 32-bit and 64-bit in Windows 7. InWindows 8 the number is the same for the 32-bit version, but for 64-bit EXE filesget 17 bits and DLLs 19, if the computer have more than 4GB RAM. In Windows7, the stack have 14 bits of entropy, which gives a total of 16384 possible baseaddresses. An interesting thing here is that Symantec did some experiements, and

Page 10: Fighting buffer overflows with Address Space Layout Randomization

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]

Page 11: Fighting buffer overflows with Address Space Layout Randomization

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 [Russinovichet al. 2012]

found that in reality, the number where not so high. Their experiment showed thatthe stack only got 8568 different base addresses, that is only 52% of what is shouldbe [Whitehous 2008] [Whitehous 2007]. In Windows 8 the entropy for the stackhave increased to 17 bits, which give a total of 131072 different base addresses. Noresearch was found to support if this is a fact in reality too. If Windows 8 is runningwith 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, althoughthere isn’t much information available on the subject. According to [Russinovichet al. 2012] Windows 8 have 64 possible base addresses for 32-bit drivers, and 256for 64-bit drivers.

To check if a process is running under the protection of ASLR, one can use aprogram 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, althoughthe screenshot is taken from Windows 8.1, which should force ASLR, but apparentlynot always.

Example of other ASLR statuses seen in Process explorer is shown below:

svchost . exe − Enabledexp lo r e . exe − High Entropy , Force Relocatecmd . exe − High Entropy

6.2 Apple OS X

ASLR first appeared in OS X 10.5 Leopard in 2007, but according to the worldfamous Mac hacker, Charlie Miller, this can hardly be called ASLR since it onlyrandomizes some of the libraries. True ASLR requires, as mentioned, randomizationof all libraries, executables, the stack and the heap [Miller and Zovi 2009]. In 2009

Page 12: Fighting buffer overflows with Address Space Layout Randomization

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 theASLR implementation, which made the biggest competitor Windows Vista, andthe then newly released Windows 7 more secure. Even though the lack of goodASLR implementation, there was still a perception that the security in OS X wasgood. This relied mostly on the fact that OS X still had a very little marked sharecompared 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 tohave better security than Windows 7 [Softpedia 2011]. Up until the release of OSX 10.8 Mountain Lion in 2012, ASLR was only implemented for the user space inmemory, but from now on the kernel space was also included, which made it harderto exploit the low-level functions. ASLR in the OS X kernel was improved in OSX 10.9 Mavericks, which was released in 2013 [Apple 2013]. Most of the technicaldetails of how ASLR is implemented in OS X is not publicly known, and thereforenot discussed in this paper. Apple is still denying Saltzer and Schroeders designprinciple on open design from 1975 [Saltzer and Schroeder 1975], and in many ways

Page 13: Fighting buffer overflows with Address Space Layout Randomization

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[Muller 2008], but had been available with the Pax patch from 2001 [ThePaxTeam2001]. The first implementation did not have randomization of all memory areas,only areas like the stack and shared libraries [Kernelnewbies 2005]. There were alsoseveral complains about the first implementation, since the randomisation of thestack only occurred over a 64KB area, and the shared libraries within 1MB. Theauthors of the implementation excused this by saying that the area of randomisationwas going to increase in later versions [corbet 2005]. Full ASLR support and largermemory areas for randomisation came in later kernel versions, but the author of thispaper 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 October2010. 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, inLinux is that you can enable or disable ASLR globally with just changing a numberin the configuration file /proc/sys/kernel/randomize va space [Carter 2010]. Thethree different numbers are shown below with a description.

0 − ASLR d i sab l ed1 − Shared l i b r a r i e s and PIE b i n a r i e s are randomized

( c o n s e rv a t i v e )2 − Adds randomizing the s t a r t o f the brk area ,

a long with co n s e r v a t i v e 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 alllater releases [Ubuntu 2013].

The use of this configuration file, makes it possible with a very easy example ofhow ASLR is working on shared libraries, using the command ldd in Linux. Thiscommand print shared library dependencies and their memory address. With fullASLR enabled (2), it is shown below that the addresses of all shared libraries arechanging everytime they are checked:

john@ubuntu : / bin$ ldd l sl inux−vdso . so . 1 => (0 x00007 f f f c4307000 )l i b s e l i n u x . so . 1 => / l i b / x86 64−l inux−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−l inux−gnu/ l i b r t . so . 1 (0

x00007f4d60314000 )l i b a c l . so . 1 => / l i b / x86 64−l inux−gnu/ l i b a c l . so . 1 (0

x00007f4d6010b000 )l i b c . so . 6 => / l i b / x86 64−l inux−gnu/ l i b c . so . 6 (0

x00007f4d5fd43000 )l i b p c r e . so . 3 => / l i b / x86 64−l inux−gnu/ l i b p c r e . so . 3 (0

x00007f4d5fb04000 )l i bp th r ead . so . 0 => / l i b / x86 64−l inux−gnu/ l i bp th r ead . so . 0 (0

x00007f4d5f8e6000 )

Page 14: Fighting buffer overflows with Address Space Layout Randomization

Fighting buffer overflows withAddress Space Layout Randomization · 14

l i b d l . so . 2 => / l i b / x86 64−l inux−gnu/ l i b d l . so . 2 (0x00007f4d5f6e2000 )

/ l i b 6 4 / ld−l inux−x86−64. so . 2 (0 x00007f4d6075b000 )l i b a t t r . so . 1 => / l i b / x86 64−l inux−gnu/ l i b a t t r . so . 1 (0

x00007f4d5f4dd000 )john@ubuntu : / bin$ ldd l sl inux−vdso . so . 1 => (0 x00007 f f f 99b f e000 )l i b s e l i n u x . so . 1 => / l i b / x86 64−l inux−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−l inux−gnu/ l i b r t . so . 1 (0

x00007fd728a47000 )l i b a c l . so . 1 => / l i b / x86 64−l inux−gnu/ l i b a c l . so . 1 (0

x00007fd72883e000 )l i b c . so . 6 => / l i b / x86 64−l inux−gnu/ l i b c . so . 6 (0

x00007fd728476000 )l i b p c r e . so . 3 => / l i b / x86 64−l inux−gnu/ l i b p c r e . so . 3 (0

x00007fd728237000 )l i bp th r ead . so . 0 => / l i b / x86 64−l inux−gnu/ l i bp th r ead . so . 0 (0

x00007fd728019000 )l i b d l . so . 2 => / l i b / x86 64−l inux−gnu/ l i b d l . so . 2 (0

x00007fd727e15000 )/ l i b 6 4 / ld−l inux−x86−64. so . 2 (0 x00007fd728e8e000 )l i b a t t r . so . 1 => / l i b / x86 64−l inux−gnu/ l i b a t t r . so . 1 (0

x00007fd727c10000 )john@ubuntu : / bin$ ldd l sl inux−vdso . so . 1 => (0 x00007 f f f 3a97c000 )l i b s e l i n u x . so . 1 => / l i b / x86 64−l inux−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−l inux−gnu/ l i b r t . so . 1 (0

x00007fe563ba6000 )l i b a c l . so . 1 => / l i b / x86 64−l inux−gnu/ l i b a c l . so . 1 (0

x00007fe56399d000 )l i b c . so . 6 => / l i b / x86 64−l inux−gnu/ l i b c . so . 6 (0

x00007fe5635d5000 )l i b p c r e . so . 3 => / l i b / x86 64−l inux−gnu/ l i b p c r e . so . 3 (0

x00007fe563396000 )l i bp th r ead . so . 0 => / l i b / x86 64−l inux−gnu/ l i bp th r ead . so . 0 (0

x00007fe563178000 )l i b d l . so . 2 => / l i b / x86 64−l inux−gnu/ l i b d l . so . 2 (0

x00007fe562f74000 )/ l i b 6 4 / ld−l inux−x86−64. so . 2 (0 x00007fe563fed000 )l i b a t t r . so . 1 => / l i b / x86 64−l inux−gnu/ l i b a t t r . so . 1 (0

x00007fe562d6f000 )

With ASLR disabled (0), the below result show that the addresses to sharedlibraries remain the same during three checks with ldd:

john@ubuntu : / bin$ ldd l s

Page 15: Fighting buffer overflows with Address Space Layout Randomization

Fighting buffer overflows withAddress Space Layout Randomization · 15

l inux−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−l inux−gnu/ l i b s e l i n u x . so . 1 (0

x00007 f f f f 7dbe000 )l i b r t . so . 1 => / l i b / x86 64−l inux−gnu/ l i b r t . so . 1 (0

x00007 f f f f 7bb6000 )l i b a c l . so . 1 => / l i b / x86 64−l inux−gnu/ l i b a c l . so . 1 (0

x00007 f f f f 79ad000 )l i b c . so . 6 => / l i b / x86 64−l inux−gnu/ l i b c . so . 6 (0

x 0 0 0 0 7 f f f f 7 5 e 5 0 0 0 )l i b p c r e . so . 3 => / l i b / x86 64−l inux−gnu/ l i b p c r e . so . 3 (0

x00007 f f f f 73a6000 )l i bp th r ead . so . 0 => / l i b / x86 64−l inux−gnu/ l i bp th r ead . so . 0 (0

x00007 f f f f 7188000 )l i b d l . so . 2 => / l i b / x86 64−l inux−gnu/ l i b d l . so . 2 (0

x 0 0 0 0 7 f f f f 6 f 8 4 0 0 0 )/ l i b 6 4 / ld−l inux−x86−64. so . 2 (0 x0000555555554000 )l i b a t t r . so . 1 => / l i b / x86 64−l inux−gnu/ l i b a t t r . so . 1 (0

x 0 0 0 0 7 f f f f 6 d 7 f 0 0 0 )john@ubuntu : / bin$ ldd l sl inux−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−l inux−gnu/ l i b s e l i n u x . so . 1 (0

x00007 f f f f 7dbe000 )l i b r t . so . 1 => / l i b / x86 64−l inux−gnu/ l i b r t . so . 1 (0

x00007 f f f f 7bb6000 )l i b a c l . so . 1 => / l i b / x86 64−l inux−gnu/ l i b a c l . so . 1 (0

x00007 f f f f 79ad000 )l i b c . so . 6 => / l i b / x86 64−l inux−gnu/ l i b c . so . 6 (0

x 0 0 0 0 7 f f f f 7 5 e 5 0 0 0 )l i b p c r e . so . 3 => / l i b / x86 64−l inux−gnu/ l i b p c r e . so . 3 (0

x00007 f f f f 73a6000 )l i bp th r ead . so . 0 => / l i b / x86 64−l inux−gnu/ l i bp th r ead . so . 0 (0

x00007 f f f f 7188000 )l i b d l . so . 2 => / l i b / x86 64−l inux−gnu/ l i b d l . so . 2 (0

x 0 0 0 0 7 f f f f 6 f 8 4 0 0 0 )/ l i b 6 4 / ld−l inux−x86−64. so . 2 (0 x0000555555554000 )l i b a t t r . so . 1 => / l i b / x86 64−l inux−gnu/ l i b a t t r . so . 1 (0

x 0 0 0 0 7 f f f f 6 d 7 f 0 0 0 )john@ubuntu : / bin$ ldd l sl inux−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−l inux−gnu/ l i b s e l i n u x . so . 1 (0

x00007 f f f f 7dbe000 )l i b r t . so . 1 => / l i b / x86 64−l inux−gnu/ l i b r t . so . 1 (0

x00007 f f f f 7bb6000 )l i b a c l . so . 1 => / l i b / x86 64−l inux−gnu/ l i b a c l . so . 1 (0

x00007 f f f f 79ad000 )l i b c . so . 6 => / l i b / x86 64−l inux−gnu/ l i b c . so . 6 (0

x 0 0 0 0 7 f f f f 7 5 e 5 0 0 0 )

Page 16: Fighting buffer overflows with Address Space Layout Randomization

Fighting buffer overflows withAddress Space Layout Randomization · 16

l i b p c r e . so . 3 => / l i b / x86 64−l inux−gnu/ l i b p c r e . so . 3 (0x00007 f f f f 73a6000 )

l i bp th r ead . so . 0 => / l i b / x86 64−l inux−gnu/ l i bp th r ead . so . 0 (0x00007 f f f f 7188000 )

l i b d l . so . 2 => / l i b / x86 64−l inux−gnu/ l i b d l . so . 2 (0x 0 0 0 0 7 f f f f 6 f 8 4 0 0 0 )

/ l i b 6 4 / ld−l inux−x86−64. so . 2 (0 x0000555555554000 )l i b a t t r . so . 1 => / l i b / x86 64−l inux−gnu/ l i b a t t r . so . 1 (0

x 0 0 0 0 7 f f f f 6 d 7 f 0 0 0 )

6.4 Android

In the Android operating system ASLR was introduced in version 4.0 Ice CreamSandwich in 2010, but only partial. Only a few certain memory areas was ran-domised, and attacks like return oriented programming was not prevented, sincethe 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 issomething Google is working with for future releases [AndroidOpenSourceProject2013] [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. InIce Cream Sandwich, the number in the file was 1, but from Jelly Bean it waschanged to 2 The number of bits used in the randomisation entropy in Android isunknown, but since Android at the moment is a 32 bit operating system, the bitsused 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 eachtime 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 inplace. Although iOS was released in 2007, ASLR first appeared in iOS 4.3 in March2011, but before this it was available to Jailbroken iOS devices using an extensioncalled Antid0te by Stefan Esser [Esser 2012]. For Jailbreaking, the introduction ofASLR was no show stopper, and jailbreakme.com soon had support for iOS up to4.3.3. This was possible because a serious vulnerability made it possible to bothread and write from memory. This in turn made it possible for an exploit to read

Page 17: Fighting buffer overflows with Address Space Layout Randomization

Fighting buffer overflows withAddress Space Layout Randomization · 17

the memory address of some nearby pointers, and then get control of the processby writing shellcode to memory and execute it [Miller and Zovi 2012]. Up untiliOS 6, iOS only had ASLR in the user space of memory, but from here on they alsoimplemented kernel space randomisation [Threatpost 2012]. The same goes withiOS as with Android, the number of bits used for entropy is unknown, but since itis a 32 bit operating system the number needs to be relatively low, which causesthe ASLR implementation to be relatively weak. Not much more is known aboutASLR 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 programmersstupidity, buffer overflow is still a problem, and because of this the developers ofoperating systems need to build in protection mechanisms like for example DataExecution Prevention and Address Space Layout Randomization. All of the mostused operating systems today have ASLR built in, but the road to this have beenlong. Both Linux, Windows, OS X, Android and iOS, were first released withoutASLR support. Linux was first out, in 2005, but already from 2001 ASLR wasavailable with the use of the Pax patch. In 2006 and 2007, OS X and Windows wasreleased with ASLR support, but only partial. This have been improved for both ofthem up until OS X 10.9 and Windows 8.1. iOS and Android is the newest of today’smost used operating systems, with ASLR support from 2011 and 2012, though nota full implementation at first. iOS and Android, together with OS X, was the mostdifficult operating systems to find information about, especially on how ASLR wasimplemented. The biggest difference from the early ASLR implementations, to theones 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. Stillvulnerabilities is being exploited, both by bypassing ASLR and by using moduleswithout ASLR support. So there is still improvements to be made. So, what willthe 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.

Page 18: Fighting buffer overflows with Address Space Layout Randomization

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.

Muller, 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.

Page 19: Fighting buffer overflows with Address Space Layout Randomization

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 byan exploit program. US Patent 5,949,973.