fighting buffer overflows with address space layout randomization

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

Author: john-andre-bjorkhaug

Post on 20-Jun-2015

319 views

Category:

Technology


0 download

Embed Size (px)

TRANSCRIPT

  • 1. Fighting buer overows 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 nds 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 dene 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 overow attacks like stack overow and heap overow. 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 ve 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, buer overows 1. INTRODUCTION In the 1960s and 1970s stack buer overows were among the rst 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 buer overow. 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, buer overow are still among the vulnerabilities that is exploited most frequently in the wild. Stack buer overows, and buer overows in general, is possible because of the lack of proper boundary checking of variables in applications, which causes memory corruption. In stack buer overows 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 buer overow vulnerability in the Unix service nger, in addition to some other vulnerabilities,

2. Fighting buer overows 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 Marko 1995, p- 321]. Up until 1995 there were not much more talk about buer overows, 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 prot in Phrack magazine number 49. This was a step-by-step tutorial on how to exploit stack buer overows, 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 buer overows. This paper will discuss more details of buer overows, both stack and heap, in Chapter 3. Smashing the stack attacks was rst 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 buer, 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 nd 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 rst important to understand details of the dierent 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 buer overows 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 nd information about. Section 5 gives a conclusion of the paper. 2. RELATED WORK Most computer security books describe the basic of buer overows and specically also stack overow and in some degree heap overows. Books like [Gollmann 2012] 3. Fighting buer overows 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 dierent overows, and how to write exploits to circumvent protection mechanisms is discussed. The ultimate paper on stack overows is the 1996 paper Smashing the stack for fun and prot 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 dierent imple- mentations in dierent 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 dierent 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 ocial 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 Hackers Handbook [Miller and Zovi 2009] and iOS Hackers 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 Apples 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 eectiveness of ne-grained address space layout randomization from 2013 [Snow et al. 2013]. I have not been able to nd 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 dierent 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 dierent areas are placed. Let us now take a look at why this is bad. 4. Fighting buer overows withAddress Space Layout Randomization 4 3.1 Buer overow Buer overows 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 buers, and if the boundary checking of the data going in to the variable is not properly done, the buer will overow if the value assigned to the variable exceed the size of the allocated size, and you have a Buer overow [Gollmann 2012]. According to the RSOS (Research in Secure Operating Systems) study conducted in the 1970s, vulnerabilities like buer overow 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 ltering. 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 buer overow 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 buer overows 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 buer overow 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, doesnt automacigally mitigate the problem of buer overows, 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 theyve 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 buer overows today, there is basically two kind of buers an attacker can overwrite, the Stack and the Heap [Klein 2011]. 3.1.1 Stack overow. 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 buer overows is possible [Harris et al. 201, p- 182]. When a program calls a function, for example void func(char * foo), 5. Fighting buer overows 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 lling 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 overows, when more data are copied into the functions local variables, the saved frame pointer and return address will be overwritten. In stack overows, the return address is the most important part, since this controls where in memory the program shall return to when the function is nished. 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 overow 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 buer overow. 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 buer overows withAddress Space Layout Randomization 6 Fig. 1. A typical stack before and after a stack overow 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 overows. 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 les read into memory by the process that owns the heap. That said, heap overows are usually just as dangerous as stack overows. By overowing the heap, important user data can be overwritten, but that is not the worst thing. Heap overows can also be used to overwrite function pointers that may be living in memory, and by that redirect the control ow of the program to malicious code. An example of a code that is vulnerable to heap buer overow is shown below. The programs takes an argument as input and copies it into a 256Byte long buer allocated by malloc() on the heap. If the argument is longer than 256Bytes, we have a heap buer overow [OWASP 2009]. int main ( int argc , char argv [ ] ) { char foobar ; buf = ( char ) malloc (256); strcpy ( foobar , argv [ 1 ] ) ; } Heap overow are also tried mitigated using ASLR. 7. Fighting buer overows withAddress Space Layout Randomization 7 4. INTRODUCING ASLR The term Address Space layout Randomization, was rst 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 rst 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 buer ow 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 nd 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 dierent 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 xed [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 Zovi 2009]. 4Page EXec 8. Fighting buer overows 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 eective 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 dierence in both when ASLR was implemented, and how it is implemented in dierent 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[Muller 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. Simplied 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 ag 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 buer overows 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 dierent 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 les 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 buer overows 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 buer overows withAddress Space Layout Randomization 11 Fig. 5. The number of bits used for the dierent 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 dierent 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 dierent 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 isnt 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 rst 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 buer overows 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 buer overows 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 [ThePaxTeam 2001]. The rst 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 rst 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 nd 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 dierence 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 conguration le /proc/sys/kernel/randomize va space [Carter 2010]. The three dierent 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 conguration le, 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: [email protected] :/ bin$ ldd l s linuxvdso . so .1 => (0 x00007fffc4307000 ) l i b s e l i n u x . so .1 => / l i b /x86 64linuxgnu/ 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 64linuxgnu/ l i b r t . so .1 (0 x00007f4d60314000 ) l i b a c l . so .1 => / l i b /x86 64linuxgnu/ l i b a c l . so .1 (0 x00007f4d6010b000 ) l i b c . so .6 => / l i b /x86 64linuxgnu/ l i b c . so .6 (0 x00007f4d5fd43000 ) l i b p c r e . so .3 => / l i b /x86 64linuxgnu/ l i b p c r e . so .3 (0 x00007f4d5fb04000 ) libpthread . so .0 => / l i b /x86 64linuxgnu/ libpthread . so .0 (0 x00007f4d5f8e6000 ) 14. Fighting buer overows withAddress Space Layout Randomization 14 l i b d l . so .2 => / l i b /x86 64linuxgnu/ l i b d l . so .2 (0 x00007f4d5f6e2000 ) / lib64 /ldlinuxx86 64. so .2 (0 x00007f4d6075b000 ) l i b a t t r . so .1 => / l i b /x86 64linuxgnu/ l i b a t t r . so .1 (0 x00007f4d5f4dd000 ) [email protected] :/ bin$ ldd l s linuxvdso . so .1 => (0 x00007fff99bfe000 ) l i b s e l i n u x . so .1 => / l i b /x86 64linuxgnu/ 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 64linuxgnu/ l i b r t . so .1 (0 x00007fd728a47000 ) l i b a c l . so .1 => / l i b /x86 64linuxgnu/ l i b a c l . so .1 (0 x00007fd72883e000 ) l i b c . so .6 => / l i b /x86 64linuxgnu/ l i b c . so .6 (0 x00007fd728476000 ) l i b p c r e . so .3 => / l i b /x86 64linuxgnu/ l i b p c r e . so .3 (0 x00007fd728237000 ) libpthread . so .0 => / l i b /x86 64linuxgnu/ libpthread . so .0 (0 x00007fd728019000 ) l i b d l . so .2 => / l i b /x86 64linuxgnu/ l i b d l . so .2 (0 x00007fd727e15000 ) / lib64 /ldlinuxx86 64. so .2 (0 x00007fd728e8e000 ) l i b a t t r . so .1 => / l i b /x86 64linuxgnu/ l i b a t t r . so .1 (0 x00007fd727c10000 ) [email protected] :/ bin$ ldd l s linuxvdso . so .1 => (0 x00007fff3a97c000 ) l i b s e l i n u x . so .1 => / l i b /x86 64linuxgnu/ 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 64linuxgnu/ l i b r t . so .1 (0 x00007fe563ba6000 ) l i b a c l . so .1 => / l i b /x86 64linuxgnu/ l i b a c l . so .1 (0 x00007fe56399d000 ) l i b c . so .6 => / l i b /x86 64linuxgnu/ l i b c . so .6 (0 x00007fe5635d5000 ) l i b p c r e . so .3 => / l i b /x86 64linuxgnu/ l i b p c r e . so .3 (0 x00007fe563396000 ) libpthread . so .0 => / l i b /x86 64linuxgnu/ libpthread . so .0 (0 x00007fe563178000 ) l i b d l . so .2 => / l i b /x86 64linuxgnu/ l i b d l . so .2 (0 x00007fe562f74000 ) / lib64 /ldlinuxx86 64. so .2 (0 x00007fe563fed000 ) l i b a t t r . so .1 => / l i b /x86 64linuxgnu/ 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: [email protected] :/ bin$ ldd l s 15. Fighting buer overows withAddress Space Layout Randomization 15 linuxvdso . 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 64linuxgnu/ 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 64linuxgnu/ l i b r t . so .1 (0 x00007ffff7bb6000 ) l i b a c l . so .1 => / l i b /x86 64linuxgnu/ l i b a c l . so .1 (0 x00007ffff79ad000 ) l i b c . so .6 => / l i b /x86 64linuxgnu/ l i b c . so .6 (0 x00007ffff75e5000 ) l i b p c r e . so .3 => / l i b /x86 64linuxgnu/ l i b p c r e . so .3 (0 x00007ffff73a6000 ) libpthread . so .0 => / l i b /x86 64linuxgnu/ libpthread . so .0 (0 x00007ffff7188000 ) l i b d l . so .2 => / l i b /x86 64linuxgnu/ l i b d l . so .2 (0 x00007ffff6f84000 ) / lib64 /ldlinuxx86 64. so .2 (0 x0000555555554000 ) l i b a t t r . so .1 => / l i b /x86 64linuxgnu/ l i b a t t r . so .1 (0 x00007ffff6d7f000 ) [email protected] :/ bin$ ldd l s linuxvdso . 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 64linuxgnu/ 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 64linuxgnu/ l i b r t . so .1 (0 x00007ffff7bb6000 ) l i b a c l . so .1 => / l i b /x86 64linuxgnu/ l i b a c l . so .1 (0 x00007ffff79ad000 ) l i b c . so .6 => / l i b /x86 64linuxgnu/ l i b c . so .6 (0 x00007ffff75e5000 ) l i b p c r e . so .3 => / l i b /x86 64linuxgnu/ l i b p c r e . so .3 (0 x00007ffff73a6000 ) libpthread . so .0 => / l i b /x86 64linuxgnu/ libpthread . so .0 (0 x00007ffff7188000 ) l i b d l . so .2 => / l i b /x86 64linuxgnu/ l i b d l . so .2 (0 x00007ffff6f84000 ) / lib64 /ldlinuxx86 64. so .2 (0 x0000555555554000 ) l i b a t t r . so .1 => / l i b /x86 64linuxgnu/ l i b a t t r . so .1 (0 x00007ffff6d7f000 ) [email protected] :/ bin$ ldd l s linuxvdso . 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 64linuxgnu/ 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 64linuxgnu/ l i b r t . so .1 (0 x00007ffff7bb6000 ) l i b a c l . so .1 => / l i b /x86 64linuxgnu/ l i b a c l . so .1 (0 x00007ffff79ad000 ) l i b c . so .6 => / l i b /x86 64linuxgnu/ l i b c . so .6 (0 x00007ffff75e5000 ) 16. Fighting buer overows withAddress Space Layout Randomization 16 l i b p c r e . so .3 => / l i b /x86 64linuxgnu/ l i b p c r e . so .3 (0 x00007ffff73a6000 ) libpthread . so .0 => / l i b /x86 64linuxgnu/ libpthread . so .0 (0 x00007ffff7188000 ) l i b d l . so .2 => / l i b /x86 64linuxgnu/ l i b d l . so .2 (0 x00007ffff6f84000 ) / lib64 /ldlinuxx86 64. so .2 (0 x0000555555554000 ) l i b a t t r . so .1 => / l i b /x86 64linuxgnu/ 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 le /proc/sys/kernel/randomize va space again, to see how ASLR is implemented. In Ice Cream Sandwich, the number in the le 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 rst versions of iOS, the were very few security protection mechanisms in place. Although iOS was released in 2007, ASLR rst 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 buer overows 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, buer overow 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 rst released without ASLR support. Linux was rst 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 todays most used operating systems, with ASLR support from 2011 and 2012, though not a full implementation at rst. iOS and Android, together with OS X, was the most dicult operating systems to nd information about, especially on how ASLR was implemented. The biggest dierence 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 buer overows 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 hackers 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 hunters 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: Buer overows 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 eectiveness of dep and aslr. http://blogs.technet.com/b/srd/archive/2010/12/08/on-the-eectiveness-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 Hackers Handbook. Wiley. Miller, C. and Zovi, D. 2012. The iOS Hackers Handbook. Wiley. Muller, T. 2008. Aslr smack & laugh reference. In Seminar on Advanced Exploitation Techniques. One, A. 1996. Smashing the stack for fun and prot. Phrack 7, 49. OWASP. 2009. Heap overow. https://www.owasp.org/index.php/Heap overow. 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. OReilly Media, Inc. Saltzer, J. H. and Schroeder, M. D. 1975. The protection of information in computer systems. Proceedings of the IEEE 63, 9, 12781308. Snow, K. Z., Monrose, F., Davi, L., Dmitrienko, A., Liebchen, C., and Sadeghi, A.-R. 2013. Just-in-time code reuse: On the eectiveness of ne-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 signicant security improvements. http://news.softpedia.com/news/Mac-OS-X-Lion-Brings-Signicant-Security-Improvements- 212818.shtml. Accessed : 29.nov.2013. Sotirov, A. 2009. Bypassing memory protections: The future of exploitation. In USENIX Secu- rity. 19. Fighting buer overows 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.