How the ELF Ruined Christmas Alessandro Di Federico, University of California, Santa Barbara and Politecnico di Milano; Amat Cama, Yan Shoshitaishvili, Christopher Kruegel, and Giovanni Vigna, University of California, Santa Barbara https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/di-frederico

This paper is included in the Proceedings of the 24th USENIX Security Symposium August 12–14, 2015 • Washington, D.C. ISBN 978-1-939133-11-3

Open access to the Proceedings of the 24th USENIX Security Symposium is sponsored by USENIX How the ELF Ruined Christmas

Alessandro Di Federico1,2, Amat Cama1, Yan Shoshitaishvili1, Christopher Kruegel1, and Giovanni Vigna1

1University of California, Santa Barbara, CA, USA amat,yans,chris,vigna @cs.ucsb.edu { 2Politecnico di Milano,} Milan, Italy [email protected]

Abstract vulnerabilities has finally begun to decrease in recent years, classic buffer overflows remain the third most common Throughout the last few decades, computer software has form of software vulnerability, and four other memory experienced an arms race between exploitation techniques corruption vulnerabilities pad out the top 25 [13]. leveraging memory corruption and detection/protection One reason behind the decreased prevalence of mem- mechanisms. Effective mitigation techniques, such as ory corruption vulnerabilities is the heavy investment in Address Space Layout Randomization, have significantly research on their prevention and mitigation. Specifically, increased the difficulty of successfully exploiting a vul- many mitigation techniques have been adopted in two nerability. A modern exploit is often two-stage: a first main areas: system-level hardening (such as CGroups [23], information disclosure step to identify the memory layout, AppArmor [4], Capsicum [41], and GRSecurity [18]) and and a second step with the actual exploit. However, be- application-level hardening (such as stack canaries [3], cause of the wide range of conditions under which memory Address Space Layout Randomization (ASLR), and the corruption occurs, retrieving memory layout information No-eXecute (NX) bit [8]). from the program is not always possible. In particular, Address Space Layout Randomization In this paper, we present a technique that uses the (ASLR), by placing the dynamic libraries in a random lo- dynamic loader’s ability to identify the locations of critical cation in memory (unknown to the attacker), lead attackers functions directly and call them, without requiring an to perform exploits in two stages. In the first stage, the information leak. We identified several fundamental weak attacker must use an information disclosure vulnerability, points in the design of ELF standard and dynamic loader in which information about the memory layout of the appli- implementations that can be exploited to resolve and cation (and its libraries) is revealed, to identify the address execute arbitrary library functions. Through these, we of code that represents security-critical functionality (such are able to bypass specific security mitigation techniques, as the system() library function). In the second stage, the including partial and full RELRO, which are specifically attacker uses a control flow redirection vulnerability to designed to protect ELF data-structures from being co- redirect the program’s control flow to this functionality. opted by attackers. We implemented a prototype tool, Leakless, and evaluated it against different dynamic loader However, because of the wide range of conditions under implementations, previous attack techniques, and real- which memory corruptions occur, retrieving this informa- life case studies to determine the impact of our findings. tion from the program is not always possible. For example, Among other implications, Leakless provides attackers memory corruption vulnerabilities in parsing code (e.g., with reliable and non-invasive attacks, less likely to trigger decoding images and video) often take place without a intrusion detection systems. direct line of communication to an attacker, precluding the possibility of an information disclosure. Without this in- formation, performing an exploit against ASLR-protected 1 Introduction binaries using current techniques is often infeasible or unreliable. Since the first widely-exploited buffer overflow used by the As noted in [36], despite the race to harden applications 1998 Morris worm [27], the prevention, exploitation, and and systems, the security of some little-known aspects of mitigation of memory corruption vulnerabilities have oc- application binary formats and the system components cupied the time of security researchers and cybercriminals using them, have not received much scrutiny. In particular alike. Even though the prevalence of memory corruption we focus on the dynamic loader, a userspace component of

1 USENIX Association 24th USENIX Security Symposium 643 the operating system, responsible for loading binaries, and In summary, we make the following contributions: the libraries they depend upon, into memory. Binaries use • We develop a new, architecture- and platform- the dynamic loader to support the resolution of imported agnostic attack, using functionality inherent in ELF- symbols. Interestingly, this is the exact behavior that an based system that supports dynamic loading, to en- attacker of a hardened application attempts to reinvent by able an attacker to execute arbitrary library functions leaking a library’s address and contents. without an information disclosure vulnerability. Our insight is that a technique to eliminate the need for • We detail, and overcome, the challenges of imple- an information disclosure vulnerability could be developed menting our system for different dynamic loader by abusing the functionality of the dynamic loader. Our implementations and in the presence of multiple technique leverages weaknesses in the dynamic loader and mitigation techniques (including RELRO). in the general design of the ELF format to resolve and exe- • Finally, we perform an in-depth evaluation, including cute arbitrary library functions, allowing us to successfully a case study of previously complicated exploits that exploit hardened applications without the need for an infor- are made more manageable with our technique, an as- mation disclosure vulnerability. Any library function can sessment of the security of several different dynamic be executed with this technique, even if it is not otherwise loader implementations, a survey of the applicability used by the exploited binary, as long as the library that it of our technique to different operating system config- resides in is loaded. Since almost every binary depends urations, and a measurement of the improvement in on the C Library, this means our technique allows us to the length of ROP chains produced by Leakless. execute security-critical functions such as system() and execve(), allowing arbitrary command execution. We will also show application-specific library functions can be 2 Related Work: re-used to perform sophisticated and stealthy attacks. The The Memory Corruption Arms Race presented technique is reliable, architecture-agnostic, and does not require the attacker to know the version, layout, The memory corruption arms race (i.e., the process of content, or any other unavailable information about the defenders developing countermeasures against known library and library function in question. exploit techniques, and attackers coming up with new We implemented our ideas in a prototype tool, called exploitation techniques to bypass these countermeasures) Leakless1. To use Leakless, the attacker must possess has been ongoing for several decades. While the history the target application, and have the ability to exploit the of this race has been documented elsewhere [37], this vulnerability (i.e., hijack control flow). Given this infor- section focuses on the sequence of events that has required mation, Leakless can automatically construct an exploit many modern exploits to be two-stage, that is, needing an that, without the requirement of an information disclosure, information disclosure step before an attacker can achieve invokes one or more critical library functions of interest. arbitrary code execution. To evaluate our technique’s impact, we performed a Early buffer overflow exploits relied on the ability to survey of several different distributions of Linux (and inject binary code (termed shellcode) into a buffer, and FreeBSD) and identified that the vast majority of binaries overwrite a return address on the stack to point into this in the default installation of these distributions are suscep- buffer. Subsequently, when the program would return from tible to the attack carried out by Leakless, if a memory its current function, execution would be redirected to the corruption vulnerability is present in the target binary. We attacker’s shellcode, and the attacker would gain control also investigated the dynamic loader implementations of of the program. various C Libraries, and found that most of them are sus- As a result, security researchers introduced another ceptible to Leakless’ techniques. Additionally, we showed mitigation technique: the NX bit. The NX bit has the effect that a popular mitigation technique, RELocation Read- of preventing memory areas not supposed to contain code Only (RELRO), which protects library function calls from (typically, the stack) from being executed. being redirected by an attacker, is completely bypassable The NX bit has pushed attackers to adapt the concept by Leakless. Finally, we compared the length of Leakless’ of code reuse: using functionality already in the program ROP chains against ROP compilers implementing similar (such as system calls and security-critical library functions) functionality. Leakless produces significantly shorter ROP to accomplish their goals. In return-into-libc exploits [30, chains than existing techniques, which, as we show, allows 39], an attacker redirects the control flow directly to a it to be used along with a wider variety of exploits than sensitive libc function (such as system()) with the proper similar attacks created by traditional ROP compilers. arguments to perform malicious behavior, instead of using injected shellcode. 1The source code is available at: https://github.com/ To combat this technique, a system-level hardening ucsb-seclab/leakless technique named Address Space Layout Randomization

2 644 24th USENIX Security Symposium USENIX Association (ASLR) was developed. When ASLR is in place, the single-stage, platform-independent, general technique, and attacker does not know the location of libraries, in fact, is able to function in the presence of such mitigations. the program’s memory layout (the locations of libraries, In the next section, we will describe how the dynamic the stack, and the heap) is randomized at each execution. loader works, and afterwards will show how we abuse this Because of this, the attacker does not know where in the functionality to perform our attack. library to redirect the control flow in order to execute specific functions. Worse, even if the attacker is able to 3 The Dynamic Loader determine this information, he is still unable to identify the location of specific functions inside the library unless The dynamic loader is a component of the userspace he is in possession of a copy of the library. As a result, execution environment that facilitates loading the libraries an attacker usually has to leak the contents of the library required by an application at start time and resolving itself and parse the code to identify the location of critical the dynamic symbols (functions or global variables) that functions. To leak these libraries, attackers often reuse are exported by libraries and used by the application. small chunks of code (called gadgets) in the program’s In this section, we will describe how dynamic symbol code segment to disclose memory locations. These gadgets resolution works on systems based on the ELF binary are usually combined by writing their addresses onto object specification [33]. the stack and consecutively returning to them. Thus, ELF is a standard format common to several Unix-like this technique is named Return Oriented Programming platforms, including GNU/Linux and FreeBSD, and is (ROP) [35]. defined independently from any particular dynamic loader ROP is a powerful tool for attackers. In fact, it has been implementation. Since Leakless mostly relies on standard shown that a “Turing-complete” set of ROP gadgets can be ELF features, it is easily applicable to a wide range of found in many binaries and can be employed, with the help systems. of a ROP compiler, to carry out exploitation tasks [34]. However, because of their generality, ROP compilers tend 3.1 The ELF Object to produce long ROP chains that, depending on the specific An application comprises a main binary ELF file (the details of a vulnerability, are “too big to be useful” [22]. executable) and several dynamic libraries, also in ELF Later, we will show that Leakless produces relatively format. Each ELF object is composed of segments, and short ROP chains, and, depending on present mitigations, each segment holds one or more sections. requires very few gadgets. Additionally, Leakless is able Each section has a conventional meaning. For instance, to function without a Turing-complete gadget set. the .text section contains the code of the program, the .data In real-world exploits, an attacker usually uses an infor- section contains its writeable data (such as global .rodata mation disclosure attack to leak the address or contents variables), and the section contains the read-only of a library, then uses this information to calculate the data (such as constants and strings). The list of sections is Elf Shdr correct address of a security-critical library function (such stored in the ELF file as an array of structures. as system()), and finally sends a second payload to the Note that there are two versions of each ELF structure: Elf32 Rel vulnerable application that redirects the control flow to one version for 32-bit ELF binaries (e.g., ) and Elf64 Rel call the desired function. one for 64-bit (e.g., ). We ignore this detail for the sake of simplicity, except in specific cases where it is In fact, we observed that that the goal of finding the relevant to our discussion. address of a specific library function is actually already implemented by the dynamic loader, an OS component 3.2 Dynamic Symbols and Relocations that facilitates the resolution of dynamic symbols (i.e., In this section, we will give a summary of the data determining the addresses of library functions). Thus, structures involved in ELF symbol resolution. Figure 1 we realized that we could leverage the dynamic loader to gives an overview of these data structures and their mutual remove the information disclosure step, and craft exploits, relationships. which would work without the need of an information An ELF object can export symbols to and import sym- disclosure attack. Since our attack does not require an bols from other ELF objects. A symbol represents a information leak step, we call it Leakless. function or a global variable and is identified by a name. The concept of using the dynamic loader as part of the Each symbol is described by a corresponding Elf Sym exploitation process was briefly explored in the context of structure. This structure, instances of which comprise return-into-libc attacks [15,21,30]. However, existing tech- the .dynsym ELF section, contains the following fields niques are extremely situational [30], platform-dependent, relevant to our work: require two stages [21], or are susceptible to current mit- st name. An offset, relative to the start of the .dynstr igation techniques such as RELRO [30], which we will section, where the string containing the name of the discuss in future sections. Leakless, on the other hand, is a symbol is located.

3 USENIX Association 24th USENIX Security Symposium 645 dl runtime resolve(link map obj, reloc index) entry in the GOT. After symbol resolution, this GOT entry contains the .rel.plt .dynsym .dynstr address of the actual function, in the imported library, and ...... r offset st name read 0 execution continues seamlessly into this function. When Rel \ r info Sym st info ... Elf caller Elf the function returns, control flow returns to the of ...... printf 0 ... \ r offset ...

Rel the PLT stub, and the rest of the PLT stub is not executed. st name r info Elf ... Sym st info However, at program startup, GOT entries are initialized

Elf ...... with an address pointing to the second instruction of the associated PLT stub. This part of the stub will push onto the stack an identifier of the imported function (in the Figure 1: The relationship between data structures involved form of an offset to an Elf Rel instance in the .rel.plt in symbol resolution (without symbol versioning). Shaded section) and jump to the PLT0 stub, a piece of code at background means read only memory. the beginning of the .plt section. In turn, the PLT0 stub, pushes the value of GOT[1] onto the stack and performs an indirect jump to the address of GOT[2]. These two entries st value. If the symbol is exported, the virtual address in the GOT have a special meaning and the dynamic loader of the exported function, NULL otherwise. populates them at application startup: These structures are referenced to resolve imported GOT[1]. A pointer to an internal data structure, of type symbols. The resolution of imported symbols is supported link map, which is used internally by the dynamic by relocations, described by the Elf Rel structure. In- loader and contains information about the current stances of this structure populate the .rel.plt section ELF object needed to carry out symbol resolution. (for imported functions) and the .rel.dyn section (for GOT[2]. A pointer to a function of the dynamic loader, imported global variables). In our discussion we are only called dl runtime resolve. interested to the former section. The Elf Rel structure In summary, PLT entries basically perform the following has the following fields: function call: r info. The three least significant bytes of this field are used as an unsigned index into the .dynsym section _dl_runtime_resolve(link_map_obj, reloc_index) to reference a symbol. This function uses the link map obj parameter to ac- r offset The location (as an absolute address) in mem- . cess the information it needs to resolve the desired im- ory where the address of the resolved symbol should ported function (identified by the reloc index argument) be written to. and writes the result into the appropriate GOT entry. Af- When a program imports a certain function, the linker ter dl runtime resolve resolves the imported function, will include a string with the function’s name in the control flow is passed to that function, making the resolu- .dynstr section, a symbol (Elf Sym) that refers to it in tion process completely transparent to the caller. The next the .dynsym section, and a relocation (Elf Rel) pointing time the PLT stub for the specified function is invoked to that symbol in the .rel.plt section. execution will be diverted directly to the target function. The target of the relocation (the r offset field of the Elf Rel struct) will be the address of an entry in a dedi- Listing 1: Example PLT and GOT. cated table: the Global Offset Table (GOT). This table, 100 PLT0: 196 ; .plt.got start 100 push *0x200 196 ; Empty entry which is stored in the .got.plt section, is populated by 106 jmp *0x204 196 0 the dynamic loader as it resolves the relocations in the 110 printf@plt: 200 ; link_map object 110 jmp *0x208 200 &link_map_obj .rel.plt section. 116 push #0 204 ; Resolver function 11B jmp PLT0 204 &_dl_runtime_resolve 3.3 Lazy Symbol Resolution 120 read@plt: 208 ; printf entry 120 jmp *0x20C 208 0x116 Since resolving every imported symbol and applying all 126 push #1 20C ; read entry relocations at application startup can be a costly operation, 12B jmp PLT0 20C 0x126 symbols are resolved lazily. In lazy symbol resolution, the The link map structure contains all the information address of a function (which corresponds to an entry in the that the dynamic loader needs about a loaded ELF object. GOT) is only resolved when necessary (i.e., the first time Each link map instance is an entry in a doubly-linked list the imported function is called). containing the information about all loaded ELF objects. When a program wants to calls an imported function, it instead calls a dedicated stub of code, located in the 3.4 Symbol Versioning Procedure Linkage Table (the .plt section). As shown in The ELF standard provides a mechanism to import a Listing 1, each imported function has a stub in the PLT that symbol with a specific version associated with it. This performs an unconditional indirect jump to the associated feature is used to require a function to be imported from a

4 646 24th USENIX Security Symposium USENIX Association Table 1: Entries of the .dynamic section. d tag is the in the presence of these countermeasures. key, while d value is the value. Note that the previously mentioned link map structure stores in the l info field an array of pointers to most of d tag d value d tag d value entries in the .dynamic section for internal usage. Since DT SYMTAB .dynsym DT PLTGOT .got.plt the dynamic loader trusts the content of this field implicitly, DT STRTAB .dynstr DT VERNEED .gnu.version Leakless will later be able to misuse this to its own ends. DT JMPREL .rel.plt DT VERSYM .gnu.version r 4 The Attack specific version of a library. For instance, it is possible to require the fopen C Standard Library function, as Leakless enables an attacker to call arbitrary library func- implemented in version 2.2.5 of the GNU C Standard tions, using only their name, without any information Library, using the version identifier GLIBC 2.2.5. The about the memory layout of the vulnerable program’s .gnu.version r section contains version definitions in libraries. To achieve this, Leakless abuses the dynamic the form of Elf Verdef structures. loader, forcing it to resolve and call the requested func- The association between a dynamic symbol and the tion. This is possible for the same reason that memory Elf Verdef structure that it refers to is kept in the corruption vulnerabilities are so damaging: the mixing .gnu.version section, as an array of Elf Verneed struc- of control data and non-control data in memory. In the tures, one for each entry in the dynamic symbol table. case of a stack overflow, the control data in question is a These structures have a single field: a 16-bit integer that stored return address. For the dynamic loader, the control represents an index into the .gnu.version r section. data is comprised of the various data structures that the Due to this layout, the index in the r info field of the dynamic loader uses for symbol resolution. Specifically, .dynstr Elf Rel structure is used by the dynamic loader as an the name of the function, stored in the section, is index into both the .dynsym and .gnu.version sections. analogous to a return address: it specifies a specific target This is important to understand, as Leakless will later to execute when the function is invoked. leverage this fact. The dynamic loader makes the assumption that the parameters it receives and its internal structures are trust- 3.5 The .dynamic section and RELRO worthy because it assumes that they are provided directly The dynamic loader collects all the information that it by the ELF file or by itself during initialization. However, needs about the ELF object from the .dynamic section, when an attacker is able to modify this data, the assump- which is composed of Elf Dyn structures. An Elf Dyn is tion is broken. Some dynamic loaders (FreeBSD) validate a key-value pair that stores different types of information. the input they receive. However, they still implicitly trust The relevant entries of this section, shown in Table 1, hold the control structures, which will be readily corrupted by the absolute addresses of specific sections. One exception Leakless. is the DT DEBUG entry, which holds a pointer to an internal Leakless is designed to be used by an attacker who is data structure of the dynamic loader. This is initialized by attempting to exploit an existing vulnerability. The input the dynamic loader and is used for debugging purposes. to Leakless is comprised of the executable ELF file, a set An attacker able to tamper with these values can pose of ROP gadgets of the binary (we detail what gadgets an a security risk. For this reason, a protection mechanism attacker needs in Section 5.1), and the name of a library known as RELRO (RELocation Read Only) has been function that the attacker wishes to call (typically, but not introduced in dynamic loaders. RELRO comes in two necessarily, execve()). Given this information, Leakless flavors: partial and full. outputs a ROP payload that executes the needed library Partial RELRO In this mode, some sections, including function, bypassing various hardening techniques applied .dynamic, are marked as read-only after they have to the binary in question. This ROP chain is generally very been initialized by the dynamic loader. short: depending on the mitigations present in the binary, Full RELRO In addition to partial RELRO, lazy resolu- the chain is 3 to 12 write operations. Some examples tion is disabled: all import symbols are resolved at of the output produced by Leakless are available in the startup time, and the .got.plt section is completely documentation of the Leakless code repository [17]. initialized with the final addresses of the target func- Leakless does not require any information about the tions and marked read-only. Moreover, since lazy addresses or contents of the libraries; we assume that resolution is not enabled, the GOT[1] and GOT[2] en- ASLR is enabled for all dynamic libraries and that no tries are not initialized with the values we mentioned knowledge about them is available. However we also in Section 3.3. assume that the executable is not position-independent, As we will see, RELRO poses significant complications and, thus, is always loaded in a specific location in memory. that Leakless must (and does) address in order to operate We discuss this limitation in detail in Section 7.2, and show

5 USENIX Association 24th USENIX Security Symposium 647 dl runtime resolve(l info, reloc index)

.dynsym .dynstr ...... st name read 0 .rel.plt .bss \ Sym st info printf 0 ... Elf ...... \ Elf r info ... r info Rel Rel r offset Elf r offset Elf st name ... Sym st info .bss .dynamic ...... Elf execve 0 read 0 d tag: DT STRTAB \ Dyn \ ... execve 0 d val \ ......

(b) Example of the attack presented in Section 4.2. The (a) Example of the attack presented in Section 4.1. The attacker reloc index passed to dl runtime resolve overflows the is able to overwrite the value of the DT STRTAB dynamic entry, .rel.plt section and ends up in .bss, where the attacker crafted tricking the dynamic loader into thinking that the .dynstr an Elf Rel structure. The relocation points to an Elf Sym lo- section is in .bss, where he crafted a fake string table. When the cated right afterwards overflowing the .dynsym section. In dynamic loader will try to resolve the symbol for printf it will turn the symbol will contain an offset relative to .dynstr large use a different base to reach the name of the function and will enough to reach the memory area after the symbol, which con- actually resolve (and call) execve. tains the name of the function to invoke.

Figure 2: Illustration of some of the presented attacks. Shaded background means read only memory, white background means writeable memory and bold or red means data crafted by the attacker.

how infrequently Position Independent Executables (PIE) ample execve. At this point, the attacker needs to choose binaries occur in modern OS distributions in Section 6.2. an existing symbol pointing to the correct offset in the While in most cases, Leakless works independently of fake string table and invoke the resolution of relocation the dynamic loader implementation and version that the corresponding to that symbol. This can be done by pushing target system is running, some of our attacks require minor the offset of this relocation on the stack and then jumping modifications to accommodate different dynamic loaders. to PLT0. Note that Leakless’s aim, obtaining the address of a This approach is simple, but it is only effective against library function and call it, is similar to what the dlsym binaries in which the .dynamic section is writeable. More function of libdl does. However, in practice this function sophisticated attacks must be used against binary compiled is rarely used by applications and, therefore, its address is with partial or full RELRO. not generally known to the attacker. 4.2 Bypassing Partial RELRO 4.1 The Base Case As we explained in Section 3.3, the second parameter As explained in Section 3 and illustrated in Figure 1, the of the dl runtime resolve function is the offset of an dynamic loader starts its work from a Elf Rel structure Elf Rel entry in the relocation table (.rel.plt section) in the .rel.plt, then follows the index into the .dynsym that corresponds to the requested function. The dynamic section to locate the Elf Sym structure, and finally uses loader takes this value and adds it to the base address of that to identify the name (a string in the .dynstr section) the .rel.plt to obtain the absolute address of the target of the symbol to resolve. The simplest way to call an Elf Rel structure. However most dynamic loader imple- arbitrary function would be to overwrite the string table mentations do not check the boundaries of the relocation entry of an existing symbol with the name of the desired table. This means that if a value larger than the size of the function, and then invoke the dynamic loader, but this is .rel.plt is passed to dl runtime resolve, the loader not possible, as the section containing the string table for will use the Elf Rel at the specified location, despite dynamic symbols, i.e., .dynstr, is not writeable. being outside the .rel.plt section. However, the dynamic loader obtains the address of As shown in Figure 2b, Leakless computes an index that the .dynstr section from the DT STRTAB entry of the will lead dl runtime resolve to look into a memory .dynamic section, which is at a known location and, by area under the control of the attacker. It then crafts an default, writeable. Therefore, as shown in Figure 2a, it Elf Rel structure that contains, in its r offset field, the is possible to overwrite the d val field of this dynamic address of the writeable memory location where the ad- entry with a pointer to a memory area under the control of dress of the function will be written. The r info field will, the attacker (typically the .bss or .data section). This in turn, contain an index that causes the dynamic loader to memory area would then include a single string, for ex- look into the attacker-controlled memory. Leakless stores

6 648 24th USENIX Security Symposium USENIX Association a crafted Elf Sym object at this location, which, likewise, .plt.got .dynamic .dynstr ...... got[0] holds a st name field value large enough to point into d tag: DT STRTAB read 0

got[1] Dyn \ d val

Elf printf 0 attacker-controlled memory. Finally, this location is where got[2] ...... \ Leakless stores the name of the desired function to call. ... In sum, Leakless crafts the full chain of structures [heap] .bss involved in symbol resolution, co-opting the process to ... d tag: DT STRTAB

... Dyn d val invoke the function whose name Leakless has written into l info[DT HASH] Elf ... map l info[DT STRTAB] attacker-controlled memory. After this, Leakless pushes read 0 link l info[DT SYMTAB] \ the computed offset to the fake Elf Rel structure onto the ... execve 0 ... \ ... stack and invokes PLT0. However, this approach is subject to several constraints. First, the symbol index in Elf Rel has to be positive, since the r info field is defined by the ELF standard as an Figure 3: Example of the attack presented in Section 4.3. unsigned integer. In practice, this means that the writable The attacker dereferences the second entry of the GOT memory area (e.g., the .bss section) must be located after and reaches the link map structure. In this structure he the .dynsym section. In our evaluation, this has always corrupts the entry of the l info field holding a pointer been the case. to the DT STRTAB entry in the dynamic table. Its value is Another constraint arises when the ELF makes use of set to the address of a fake dynamic entry which, in turn, the symbol versioning system described in Section 3.4. points to a fake dynamic string table in the .bss section. In this case, the Elf Rel.r info field is not just used as an index into the dynamic symbol table, but also as while in the previous attacks we were relying exclusively an index in the symbol version table (the .gnu.version on standard ELF features, in this case (and in the one section). In general, Leakless is able to automatically presented in the next section) we assume the layout of satisfy these constraints, except for x86-64 small binaries a glibc-specific structure (link map) to be known. Each using huge pages [32]. We detail the additional constraints dynamic loader implements this structure in its own way, introduced by symbol versioning in Appendix A. When the so minor modifications might be required when targeting constraints cannot be satisfied, an alternate approach must a different dynamic loader. Note that link map’s layout be adopted. This involves abusing the dynamic loader by might change among versions of the same dynamic loader. corrupting its internal data structures to alter the dynamic However, they tend to be quite stable, and, in particular, in resolution process. glibc no changes relevant to our attack have taken place 4.3 Corrupting Dynamic Loader Data since 2004. We recall that the first parameter to 4.4 The Full RELRO Situation dl runtime resolve is a pointer to a data struc- Leakless is able to bypass full RELRO protection. ture of type link map. This structure contains information When full RELRO is applied, all the relocations are about the ELF executable, and the contents of this structure resolved at load-time, no lazy resolving takes place, are implicitly trusted by the dynamic loader. Furthermore, and the addresses of the link map structure and of Leakless can obtain the address of this structure from the dl runtime resolve in the GOT are never initialized. second entry of the GOT of the vulnerable binary, whose Thus, it is not directly possible to know their addresses, location is deterministically known. which is what the general technique to bypass partial Recall from Section 3.5 that the link map structure, RELRO relies upon. in the l info field, contains an array of pointers to the However, it is possible to indirectly recover these two entries of the .dynamic section. These are the pointers values through the DT DEBUG entry in the dynamic table. that the dynamic loader uses to locate the objects that are The value of the DT DEBUG entry is set by the dynamic used during symbol resolution. As shown in Figure 3, loader at load-time to point to a data structure of type by overwriting part of this data structure, Leakless can r debug. This data structure contains information used make the DT STRTAB entry of the l info field point to a by debuggers to identify the base address of the dynamic specially-crafted dynamic entry which, in turn, points to a loader and to intercept certain events related to dynamic fake dynamic string table. Hence, the attacker can reduce loading. In addition, the r map field of this structure the situation back to the base case presented in Section 4.1. holds a pointer to the head of the linked list of link map This technique has wider applicability than the one structures. presented in the previous section, since there are no specific Leakless corrupts the first entry of the list describing the constraints, and, in particular, it is applicable also against ELF executable so that the l info entry for DT STRTAB small 64 bit ELF binaries using huge pages. However, points to a fake dynamic string table. This is presented in

7 USENIX Association 24th USENIX Security Symposium 649 dl runtime resolve(l info, reloc index)

.dynamic [heap] .plt.got ...... GOT[0] d tag: DT DEBUG r version

Dyn GOT[1] r map

d val debug Elf

... r ... GOT[2] Elf ...... d tag: DT STRTAB Dyn ...

d val l info[DT STRTAB]

...... link

l info[DT JMPREL] map ... .dynstr .bss l next .dynamic ...... d tag: DT JMPREL ... read 0 Dyn ... d tag: DT PLTGOT

d val Dyn \ Elf Elf map l info[DT PLTGOT] d val printf 0 r info Elf \ Rel ...... link r offset ... reloc target Elf .dynsym d tag: DT STRTAB Dyn ... d val st name Elf ... Sym read 0 st info \ ...... execve 0 \ ...

Figure 4: Example of the attack presented in Section 4.4. Shaded background means read only memory, white background means writeable memory and bold or red means data crafted by the attacker. The attacker goes through the DT DEBUG dynamic entry to reach the r debug structure, then, dereferencing the r map field, he gets to the link map structure of the main executable, and corrupts l info[DT STRTAB] as already seen in Section 3. Since the .got.plt section is read-only due to full RELRO, the attacker also have to forge a relocation. To do so, he corrupts l info[DT JMPREL] making it point to a fake dynamic entry in turn pointing to a relocation. This relocation refers to the existing printf symbol, but has an r offset pointing to a writeable memory area. Then the attacker also needs to recover the pointer to the dl runtime resolve function, which is not available in the GOT of the main executable due to full RELRO, therefore he dereferences the l info field of the first link map structure and gets to the one describing the first shared library, which is not protected by full RELRO. The attacker accesses the l info[DT PLTGOT] field and gets to the corresponding dynamic entry (the .dynamic on the right), and then to the .plt.got section (always on the right), at the second entry of which he can find the address of dl runtime resolve.

Figure 4. order of libraries in the linked list is deterministic, Leakless can dereference the l next entry in link map to reach dl runtime resolve After this, Leakless must invoke , the entry describing a library that is not protected by full link map passing the structure that it just corrupted as RELRO, dereference the entry in l info corresponding .dynsym the first argument and an offset into the new as to the DT PLTGOT dynamic entry, dereference its value the second parameter. However, as previously mentioned, (i.e., the base address of that library’s GOT), and read the dl runtime resolve is not available in the GOT due to address of dl runtime resolve from this GOT. full RELRO. Therefore, Leakless must look for its address in the GOT of another ELF object, namely, a library loaded Leakless must then overcome a final issue: by the application that is not protected by full RELRO. dl runtime resolve will not only call the target In most cases, only ELF executables are compiled with function, but will also try to write its address to the full RELRO, and libraries are not. This is due to the appropriate GOT entry. If this happens, the program fact that RELRO is designed to harden, at the cost of will crash, as the GOT is read-only when full RELRO performance, specific applications that are deemed “risky”. is applied. We can circumvent this issue by faking the Applying full RELRO to a shared library would impact the DT JMPREL dynamic entry in the link map structure performance of all applications making use of this library, that points to the .rel.dyn section. Leakless points it and thus, libraries are generally left unprotected. Since the to an attacker-controlled memory area and writes an

8 650 24th USENIX Security Symposium USENIX Association Elf Rel structure, with a target (r offset field) pointing namic loader implementations. We then analyzed the to a writeable memory area, referring to the symbol we binaries distributed by several popular GNU/Linux and are targeting. Therefore, when the library is resolved, BSD distributions (specifically, Ubuntu, Debian, Fedora, the address will be written to a writeable location, the and FreeBSD) to determine the percentage of binaries program will not crash, and the requested function will be that would be susceptible to our attack. Then we applied executed. Leakless in two real-world exploits against a vulnerable version of Wireshark and in a more sophisticated attack against Pidgin. Finally we used a Turing-complete ROP 5 Implementation compiler to implement the approach used in Leakless and Leakless analyzes a provided binary to identify which two other previously used techniques, and compared the of its techniques is applicable, crafts the necessary data size of the resulting chains. structures, and generates a ROP chain that implements the 6.1 Dynamic Loaders chosen technique. The discovery of the initial vulnerability To show Leakless’ generality, especially across different itself, and the automatic extraction of usable gadgets from ELF-based platforms, we surveyed several implementa- a binary are orthogonal to the scope of our work, and have tions of dynamic loaders. In particular, we found that been well-studied in the literature and implemented in the the dynamic loader part of the GNU C Standard Library real world [6, 16, 19, 20, 34, 38]. We designed Leakless to (also known as glibc and widely used in GNU/Linux dis- be compatible with a number of gadget finding techniques, tributions), several other Linux implementations such as and have implemented a manual backend (where gadgets dietlibc, uClibc and newlib (widespread in embedded sys- are provided by the user) and a backend that utilizes tems) and the OpenBSD and NetBSD implementations are ROPC [22], an automated ROP compiler prototype built vulnerable to Leakless. Another embedded library, musl, on the approach proposed by Q [34]. instead, is not susceptible to our approach since it does not We also developed a small test suite, composed of a support lazy loading. Bionic, the C Standard Library used small C program with a stack-based buffer overflow com- in Android, is also not vulnerable since it only supports piled, alternatively, with no protections, partial RELRO, PIE binaries. The most interesting case, out of all the and full RELRO. The test suite runs on GNU/Linux with loaders we analyzed, is FreeBSD’s implementation. In the x86, x86-64 and ARM architectures and with FreeBSD fact, it is the only one which performs boundary checks x86-64. on arguments passed to dl runtime resolve. All other 5.1 Required Gadgets loaders implicitly trust input arguments argument. Fur- Leakless comprises four different techniques that are thermore, all analyzed loaders implicitly trust the control used depending on the hardening techniques applied to the structures that Leakless corrupts in the course of most of binary. These different techniques require different gadgets its attacks. to be provided to Leakless. A summary of the types of In summary, out of all of the loaders we analyzed, only gadgets is presented in Table 2. The write memory gadget two are immune to Leakless by design: musl, which does is mainly used to craft data structures at known memory not support lazy symbol resolution, and bionic, which locations, while the deref write gadget to traverse and only supports PIE executables. Additionally, because corrupt data structures (in particular link map). The the FreeBSD dynamic loader performs bounds checking, deref save and copy to stack gadgets are used only the technique explained in Section 4.2 is not applicable. in the full RELRO case. The aim of the former is to However, the other techniques still work. save at a known location the address of link map and 6.2 Operating System Survey dl runtime resolve , while the latter is used to copy To understand Leakless’ impact on real-world systems, link map and the relocation index on the stack before we performed a survey of all binaries installed in default dl runtime resolve PLT0 calling , since using is not a installations of several different Linux and BSD distribu- viable solution. tions. Specifically, we checked all binaries in /sbin, /bin, For the interested reader, we provide in-depth examples /usr/sbin, and /usr/bin on these systems and classified of executions of Leakless in the presence of two different the binaries by the applicability of the techniques used sets of mitigation techniques in the documentation of the by Leakless. The distributions that we considered were Leakless code repository [17]. Ubuntu 14.10, Debian Wheezy, Fedora 20, and FreeBSD 10. We used both x86 and x86-64 versions of these sys- 6 Evaluation tems. On Ubuntu and Debian, we additionally installed the LAMP (Linux, Apache, MySQL, PHP) stack as an attempt We evaluated Leakless in four ways. First, we determined to simulate a typical server deployment configuration. the applicability of our technique against different dy- The five categories that we based our ratings on are as

9 USENIX Association 24th USENIX Security Symposium 651 Table 2: Gadgets required for the various approaches. The “Signature” column represents the name of the gadget and the parameters it accepts, while “Implementation” presents the behavior of the gadget in C-like pseudo code. The last four columns indicate whether a certain gadget is required for the corresponding approach presented in Section 4. Under RELRO, “N” indicates RELRO is disabled, “P” means partial RELRO is used, “H” stands for the partial RELRO and small 64 bit binaries using huge pages, and “F” denotes that full RELRO is enabled.

RELRO Signature Implementation N PHF write memory(destination, value) (destination)=value ∗ deref write(pointer, o f f set, value) ( (pointer)+o f f set)=value ∗ ∗ deref save (destination, pointer, o f f set) (destination)= ( (pointer)+o f f set) ∗ ∗ ∗ copy to stack(o f f set, source) (stack pointer + o f f set)= (source) ∗ ∗

follows: Unprotected Partial RELRO Partial RELRO HP Full RELRO Not susceptible

Unprotected. This category includes binaries that have 100 no RELRO or PIE. For these binaries, Leakless can apply its base case technique, explained in Sec- 80 tion 4.1. 60

Partial RELRO. Binaries that have partial RELRO, but 40

lack PIE, fall into this category. In this case, Leakless Percentage of Binaries would apply the technique described in Section 4.2. 20 Partial RELRO (huge pages). Binaries in this category 0 have partial RELRO, use huge pages, and are very Ubuntu Debian Fedora FreeBSD Ubuntu 64 Debian 64 Fedora 64 FreeBSD 64 small, therefore, they require Leakless to use the Figure 5: Classification of the binaries in default in- technique described in Section 4.3. They are included stallations of target distributions. Binaries marked as in this category. Unprotected, Partial RELRO, Partial RELRO HP and Full RELRO. To attack binaries that use full RELRO, Full RELRO require, respectively, to the attacks detailed in which comprise this category, Leakless must apply Sections 4.1, 4.2, 4.3 and 4.4, while for Not susceptible the technique presented in Section 4.4. binaries, the Leakless approach is not applicable Not susceptible. Finally, we consider binaries that use PIE to be insusceptible to Leakless (further discussion on this in Section 7.2). 6.3 Case Study: Wireshark The results of the survey, normalized to the total number We carried out a case study in applying Leakless to a of binaries in an installation, are presented in Figure 5. vulnerability in a program that does not present a direct We determined that, on Ubuntu, 84% of the binaries were line of communication to the attacker. In other words, the susceptible to at least one of our techniques and 16% were exploit must be done in one-shot, with no knowledge of protected with PIE. On Debian, Leakless can be used the layout of the address space or the contents of libraries. on 86% of the binaries. Fedora has 76% of susceptible We picked a recent (April 2014) vulnerability [7], which binaries. Interestingly, FreeBSD ships no binaries with is a stack-based buffer overflow in Wireshark’s MPEG RELRO or PIE, and is thus 100% susceptible to Leakless. protocol parser in versions 1.8.0 through 1.8.13 and 1.10.0 Additionally, we performed a survey on the shared through 1.10.6. We carried out our experiments against a libraries of the systems we considered. We found that, Wireshark 1.8.2 binary compiled with partial RELRO and on average, only 11% of the libraries had full RELRO one compiled with full RELRO. Both were compiled for protection. This has some interesting implications for x86-64 on Debian Wheezy and used the GNU C Library, Leakless: for a given binary, the likelihood of finding a without other protections such as PIE and stack canaries. loaded library without full RELRO is extremely high and, We used the manual Leakless backend to identify the even if a vulnerable binary employs RELRO, Leakless required gadgets to construct the four necessary primitives can still apply its full RELRO attack to bypass this. This (described in Section 5.1): write memory, deref write, has the effect of making RELRO basically useless as a deref save and copy to stack. In the case of Wireshark, it mitigation technique, unless it is applied system-wide. was trivial to find gadgets to satisfy all of these primitives.

10 652 24th USENIX Security Symposium USENIX Association Leakless was able to construct a one-shot exploit using Table 3: Size of the ROP chains generated by ROPC for the attacks presented in Section 4.2 and Section 4.4. In each technique presented in Section 6.5, and by Leakless’ both cases, the exploit leverages the dynamic loader in manual backend (*). The second column represents the order to call the execve function from glibc to launch an size in bytes for the setup and the first call, while the executable of our choice. third column shows the additional cost (in bytes) for each subsequent call. Finally, the fourth column indicates the 6.4 Case Study: Pidgin percentage of vulnerabilities used in Metasploit that would We also applied Leakless to Pidgin, a popular multi- be feasible to exploit with a ROP chain of the First call protocol instant-messaging client, to build a more so- size. phisticated exploit. Specifically, we wanted to perform a malicious operation without calling any anomalous sys- Technique First call Subsequent Feasibility tem call (e.g. execve("/bin/sh")) which could trigger ROPC - scan library 3468 bytes +340 bytes 16.38% intrusion detection systems. We used Pidgin 2.10.7, build- ing it from the official sources with RELRO enabled and ROPC - symbol resolution 7964 bytes +580 bytes 8.67% targeting the x86 architecture. Leakless partial RELRO 648 bytes +84 bytes 73.78% To this end, we crafted an exploit designed to mas- Leakless full RELRO 2876 bytes +84 bytes 17.44% querade itself in legitimate functionality present in the Leakless* partial RELRO 292 bytes +48 bytes 95.24% application logic: tunneling connections through a proxy. Leakless* full RELRO 448 bytes +48 bytes 88.9% The idea of the attack is that an IM service provider ex- ploits a vulnerability such as CVE-2013-6487 [14] to gain code execution, and, using Pidgin’s global proxy settings, redirects all IM traffic through a third-party server to enable chat interception. We implemented these two approaches using a Turing- Once we identified the necessary gadgets to use Leak- complete ROP compiler for x86, based on Q [34], called less with full RELRO protection, it was easy to invoke ROPC [22]. We compare these approaches against that functions contained in libpurple.so (where the core of of Leakless’ ROPC backend, in partial RELRO and full the application logic resides) to perform the equivalent of RELRO modes. For completeness, we also include the the C code shown in Listing 2. Leakless’ manual backend, with gadgets specified by the Listing 2: The Pidgin attack. user.

void *p, *a; p = purple_proxy_get_setup(0); In fact, the size of a ROP payload is critical, vulnera- purple_proxy_info_set_host(p, " legit.com"); bilities often involve an implicit limit on the size of the purple_proxy_info_set_port(p, 8080); purple_proxy_info_set_type(p, PURPLE_PROXY_HTTP); payload that can be injected into a program. To measure the impact of Leakless’ ROP chain size, we collected the a = purple_accounts_find(" usr@xmpp", "prpl- xmpp"); purple_account_disconnect(a); size limits imposed on payloads of all the vulnerability purple_account_connect(a); descriptions included in the Metasploit Framework [31], a Interestingly, some of this library-provided functionality turn-key solution for launching exploits against known is not imported into the Pidgin executable itself, and vulnerabilities in various software. We found that 946 of would be very challenging to accomplish in a single-stage the 1,303 vulnerability specifications included a maximum payload, without Leakless. payload size, with an average specified maximum payload size of 1332 bytes. To demonstrate the increase in the 6.5 ROP chain size comparison feasibility of automatically generating complex exploits, To prove the effectiveness of the Leakless approach, we we include, for each evaluated technique, the percentage compared it with two existing techniques that allow an of Metasploit vulnerabilities for which the technique can attacker to call arbitrary library functions. The first consists automatically produce short enough ROP chains. in scanning a library backwards, starting from an address in the .plt.got section, until the ELF header is found, and The results, in terms of length of the ROP chain gener- then scan forward to find a fingerprint of the function the ated for ROPC’s test binaries and feasibility against the attacker wants to invoke. This approach is feasible, but not vulnerabilities used in Metasploit, are shown in Table 3. very reliable, since different versions (or implementations) Leakless outperforms existing techniques, not only in the of a library might not be uniquely identified with a single absolute size of the ROP chain to perform the initial call, fingerprint. The second technique is more reliable, since but also in the cost of performing each additional call, it implements the full symbol resolution process, as it is which is useful in a sophisticated attack such as the one carried out by the dynamic loader. demonstrated in Section 6.4.

11 USENIX Association 24th USENIX Security Symposium 653 7 Discussion on). This means that Leakless can be used to perform any system call, in a short ROP chain, even without a system In this section, we will discuss several aspects relating to call gadget. Leakless: why the capabilities that it provides to attackers Moreover, as demonstrated in Section 6.4, Leakless are valuable, when it is most applicable, what its limitations enables easy reuse of existing functionality present in the are, and what can be done to mitigate against them. application logic. This is important for two reasons. 7.1 Leakless Applications First, this helps an attacker perform stealthy attacks by making it easier to masquerade an exploit as something Leakless represents a powerful tool in the arsenal of the application might normally do. This can be crucial exploit developers, aiding them in three main areas: func- when a standard exploitation path is made infeasible by the tionality reuse, one-shot exploitation, and ROP chains presence of protection mechanisms such as seccomp [2], shortening. AppArmor [1], or SELinux [25]. One-shot exploitation. While almost any exploit can Second, depending on the goals of the attacker, reusing be simplified by Leakless, we have designed it with the program functionality may be better than simply executing goal of enabling exploits that, without it, require an infor- arbitrary commands. Aside from the attack discussed mation disclosure vulnerability, but for which an informa- in our Pidgin case study, an attacker can, for example, tion disclosure is not feasible or desirable. A large class silently enable insecure cipher-suites, or versions of SSL, of programs that fall under this category are file format in the Firefox web browser with a single function call to parsers. SSL CipherPrefSetDefault [24]. Code that parses file formats is extremely complex and, Shorter ROP chains. As demonstrated in Section 6.5, due to the complex, untrusted input that is involved, this Leakless produces shorter ROP chains than existing tech- code is prone to memory corruption vulnerabilities. There niques. In fact, in many cases, Leakless is able to produce are many examples of this: the image parsing library ROP chains less than one kilobyte that lead to the execu- libpng had 27 CVE entries over the last decade [10], and tion of arbitrary functions. As many vulnerabilities have a libtiff had 53 [11]. Parsers of complex formats suffer limit as to the maximum size of the input that they will ffmpeg even more: the multimedia library has accumu- accept, this is an important result. For example, the vulner- lated 170 CVE entries over the last five years alone [9]. ability that we exploited in our Pidgin case study allowed This class of libraries is not limited to multimedia. Wire- a maximum ROP chain of one kilobyte. Whereas normal shark, a network packet analyzer, has 285 CVE entries, ROP compilation techniques would be unable to create au- most of which are vulnerabilities in network protocol tomatic payloads for this vulnerability, Leakless was able analysis plugins [12]. to call arbitrary functions via an automatically-produced These libraries, and others like them, are often used ROP chain that remained within the length limit. offline. The user might first download a media or PCAP file, and then parse it with the library. At the point where 7.2 Limitations the vulnerability triggers, an attacker cannot count on Leakless’ biggest limitation is the inability to handle having a direct connection to the victim to receive an Position Independent Executables (PIEs) without a prior information disclosure and send additional payloads. Fur- information disclosure. This is a general problem to any thermore, most of these formats are passive, meaning that technique that uses ROP, as the absolute addresses of (unlike, say, PDF), they cannot include scripts that the gadgets must be provided in the ROP chain. Additionally, attacker can use to simulate a two-step exploitation. As a without the base address of the binary, Leakless would be result, even though these libraries might be vulnerable, unable to locate the dynamic loader structures that it needs exploits for them are either extremely complex, unreliable, to corrupt. or completely infeasible. By avoiding the information When presented with a PIE executable, Leakless re- disclosure step, Leakless makes these exploits simpler, quires the attacker to provide the application’s base ad- reliable, and feasible. dress, which is presumably acquired via an information Functionality reuse. Leakless empowers attackers disclosure vulnerability (or, for example, by applying the to call arbitrary functions from libraries loaded by the technique presented in BROP [5]). While this breaks Leak- vulnerable application. In fact, the vulnerable application less’ ability to operate without an information disclosure, does not have to actually import this function; it just needs Leakless is likely still the most convenient way to achieve to link against the library (i.e., call any other function in exploitation, as no library locations or library contents the library). This is brings several benefits. have to be leaked. Additionally, depending on the situation, To begin with, the C Standard Library, which is linked the disclosure of just the address of the binary might be against by most applications, includes functions that wrap more feasible than the disclosure of the contents of an almost every system call (e.g., read(), execve(), and so entire library. Unlike other techniques, which may need

12 654 24th USENIX Security Symposium USENIX Association the latter, Leakless only requires the former. that provide control data for symbol resolution, could be In practice, PIEs are uncommon due to the associated marked as read-only after initialization. Such a develop- cost in terms of performance. Specifically, measurements ment would eliminate Leakless’ ability to corrupt these have shown that PIE overhead on x86 processors aver- structures and would prevent the attack from redirecting ages at 10%, while the overhead on x86-64 processors, the control flow to sensitive functions. thanks to instruction-pointer-relative addressing, averages Additionally, modifying the loading procedure at 3.6% [28]. to use a table of link map structure, and letting Because of the overhead associated with PIE, most dis- dl runtime resolve take an index in this table, instead tributions ship with PIE enabled only for those applications of a direct pointer, will break Leakless’ bypass of full deemed “risky”. For example, according to their documen- RELRO. However, this change would also break compat- tation, Ubuntu ships only 27 of their officially supported ibility with any binaries compiled before the change is packages (i.e., packages in the “main” repository) with implemented. PIE enabled, out of over 27,000 packages [40]. As shown Isolation of the dynamic loader. Isolating the dy- in Section 6.1, PIE executables comprise a minority of the namic loader from the address space of the target program executables on all of the systems that we surveyed. could be an effective countermeasure. For instance, on Nokia’s Symbian OS, which has a micro-kernel, the dy- 7.3 Countermeasures namic loader is implemented in a separate process as a There are several measures that can be taken against system server which interfaces with the kernel [26]. This Leakless, but they all have drawbacks. In this sections we guarantees that the control structures of the dynamic loader analyze the most relevant ones. cannot be corrupted by the program, and, therefore, this Position Independent Executables. A quick counter- makes Leakless virtually ineffective. However, such a measure is to make every executable on the system position countermeasure would have a considerable impact on the independent. While this would block Leakless’s automatic overall performance of applications due to the overhead of operation (as discussed in Section 7.2), it would still al- IPC (Inter-Process Communication). low the application of the Leakless technique when any In general, the mitigations either represent a runtime information disclosure does occur. For that reason, and the performance overhead (PIE or loader isolation), a load- performance overhead associated with PIE, we consider time performance overhead (non-lazy loading and system- the other countermeasures described in this section to be wide RELRO), or a modification of the loading process better solutions to the problem. (DT DEBUG disabling or loader control structure hiding). In Disabling lazy loading. When the LD BIND NOW envi- the long run, we believe that a redesign of the dynamic ronment variable is set, the dynamic loader will completely loader, with security in mind, would be extremely benefi- disable lazy loading. That is, all imports, for the program cial to the community. In the short term, there are options binary and any library it depends on, are resolved upon available to protect against Leakless, but they all come program startup. As a side-effect of this, the address of with a performance cost. dl runtime resolve does not get loaded into the GOT of any library, and Leakless cannot function. This is 8 Conclusion equivalent to enable full RELRO on the whole system, and consequently, it incurs in the same, non-negligible, In this paper, we presented Leakless, a new technique that performance overhead. leverages functionality provided by the dynamic loader to Disabling DT DEBUG. Finally, Leakless also uses the enable attackers to use arbitrary, security-critical library DT DEBUG dynamic entry, used by debuggers for inter- functions in their exploits, without having to know where cepting loading-related events, to bypass full RELRO. in the application’s memory these functions are located. Currently, this field is always initialized, opening the doors This capability allows exploits that, previously, required for Leakless’ full RELRO bypass. To close this hole, the an information disclosure step to function. dynamic loader could be modified to only initialize this Since Leakless leverages features mandated in the ELF value when a debugger is present or in the presence of an binary format specification, the attacks it implements explicitly-set environment variable. are applicable across architectures, operating systems, Better protection of loader control structures. Leak- and dynamic loader implementations. Additionally, we less heavily relies on the fact that dynamic loader control showed how our technique can be used to bypass hard- structures are easily accessible in memory, and their lo- ening schemes such as RELRO, which are designed to cations are well-known. It would be beneficial for these protect important control structures used in the dynamic structures to be better protected, or hidden in memory, resolution process. Finally, we proposed several counter- instead of being loaded at a known location. For example, measures against Leakless, discussing the advantages and as shown in [29], these structures, along with any sections disadvantages of each one.

13 USENIX Association 24th USENIX Security Symposium 655 References [15] A. Di Federico, A. Cama, Y. Shoshitaishvili, C. Kruegel, and G. Vigna. Leakless source code [1] AppArmor. http://wiki.apparmor.net/. repository. https://github.com/ucsb-seclab/ leakless. [2] A. Arcangeli. seccomp. https://www. kernel.org/doc/Documentation/prctl/ [16] S. Dudek. The Art Of ELF: Analysis and Exploita- seccomp filter.txt. tions. http://bit.ly/1a8MeEw. [3] A. Baratloo, N. Singh, and T. K. Tsai. Transparent Run-Time Defense Against Stack-Smashing Attacks. [17] T. Dullien, T. Kornau, and R.-P. Weinmann. A In USENIX Annual Technical Conference, General Framework for Automated Architecture-Independent Track, pages 251–262, 2000. Gadget Search. In WOOT, 2010. [4] M. Bauer. Paranoid penguin: an introduction to [18] M. Fox, J. Giordano, L. Stotler, and A. Thomas. Novell AppArmor. Linux Journal, 2006(148):13, Selinux and grsecurity: A case study comparing 2006. linux security kernel enhancements. 2009.

[5] A. Bittau, A. Belay, A. Mashtizadeh, D. Mazieres, [19] I. Haller, A. Slowinska, M. Neugschwandtner, and and D. Boneh. Hacking blind. In Proceedings of H. Bos. Dowsing for Overflows: A Guided Fuzzer the 35th IEEE Symposium on Security and Privacy, to Find Buffer Boundary Violations. In USENIX 2014. Security, pages 49–64, 2013. [6] S. K. Cha, T. Avgerinos, A. Rebert, and D. Brumley. https: Unleashing mayhem on binary code. In Security [20] C. Heitman and I. Arce. BARFgadgets. //github.com/programa-stic/barf-project/ and Privacy (SP), 2012 IEEE Symposium on, pages tree/master/barf/tools/gadgets 380–394. IEEE, 2012. . [7] Common Vulnerabilities and Exposures. CVE- [21] inaz2. ROP Illmatic: Exploring Universal 2014-2299. http://cve.mitre.org/cgi-bin/ ROP on glibc x86-64. http://ja.avtokyo.org/ cvename.cgi?name=CVE-2014-2299. avtokyo2014/speakers#inaz2.

[8] C. Cowan, P. Wagle, C. Pu, S. Beattie, and J. Walpole. [22] P. Kot. A Turing complete ROP compiler. https: Buffer overflows: Attacks and defenses for the vul- //github.com/pakt/ropc. nerability of the decade. In DARPA Information Survivability Conference and Exposition, 2000. DIS- [23] P. Menage. Cgroups. Available on-line at: CEX’00. Proceedings, volume 2, pages 119–129. http://www. mjmwired. net/kernel/Documentation/c- IEEE, 2000. groups. txt, 2008.

[9] CVEDetails.com. ffmpeg: CVE security vulnera- [24] Mozilla. SSL CipherPrefSetDefault. bilities. http://www.cvedetails.com/product/ https://developer.mozilla.org/en-US/ 6315/Ffmpeg-Ffmpeg.html. docs/Mozilla/Projects/NSS/SSL functions/ [10] CVEDetails.com. Libpng: Security Vulnera- sslfnc.html# SSL CipherPrefSetDefault . bilities. http://www.cvedetails.com/vendor/ 7294/Libpng.html. [25] National Security Agency. Security-Enhanced Linux. http://selinuxproject.org/. [11] CVEDetails.com. Libtiff: CVE security vulnera- bilities. http://www.cvedetails.com/product/ [26] Nokia. Symbian OS Internals - The Loader. 3881/Libtiff-Libtiff.html. http://developer.nokia.com/community/ wiki/Symbian OS Internals/10. The Loader# [12] CVEDetails.com. Wireshark: CVE security vulnera- The loader server. bilities. http://www.cvedetails.com/product/ 8292/Wireshark-Wireshark.html. [27] H. Orman. The Morris worm: a fifteen-year per- [13] CWE. CWE/SANS Top 25 Most Dangerous Soft- spective. IEEE Security & Privacy, 1(5):35–43, ware Errors. http://cwe.mitre.org/top25/. 2003. [14] N. V. Database. NVD - Detail - CVE-2013- [28] M. Payer. Too much PIE is bad for performance. 6487. http://web.nvd.nist.gov/view/vuln/ 2012. https://nebelwelt.net/publications/ detail?vulnId=CVE-2013-6487. 12TRpie/gccPIE-TR120614.pdf.

14 656 24th USENIX Security Symposium USENIX Association [29] M. Payer, T. Hartmann, and T. R. Gross. Safe Load- [41] R. N. Watson, J. Anderson, B. Laurie, and K. Kenn- ing - A Foundation for Secure Execution of Untrusted away. Capsicum: Practical Capabilities for UNIX. Programs. In Proceedings of the 2012 IEEE Sympo- In USENIX Security Symposium, pages 29–46, 2010. sium on Security and Privacy, SP ’12, pages 18–32, Washington, DC, USA, 2012. IEEE Computer Soci- A Symbol versioning challenges ety. [30] Phrack. Phrack - Volume 0xB, Issue 0x3a. http: In Section 3.4 we introduced the concept of symbol ver- //phrack.org/issues/58/4.html. sioning, and in Section 4.2 we mentioned that its us- age introduces additional constraints in the value that [31] Rapid7, Inc. The Metasploit Framework. http: Elf Rel.r info can assume. In this Appendix we illus- //www.metasploit.com/. trate these constraints, and how Leakless can automatically [32] RedHat, Inc. Huge Pages and Transparent verify and satisfy them. Huge Pages. https://access.redhat.com/ A.1 Constraints due to symbol versioning documentation/en-US/Red Hat Enterprise In presence of symbol versioning, the Elf Rel.r info Linux/6/html/Performance Tuning Guide/ field is used both as an index into the dynamic sym- s-memory-transhuge.html. bol table and as an index in the symbol version ta- ble (the .gnu.version section), which is composed by [33] Santa Cruz Operation. System V Application Elf Verneed values. An Elf Verneed value of zero or Binary Interface, 2013. http://www.sco.com/ one has a special meaning, and stops the processing of developers/gabi/latest/contents.html. the symbol version, which is a desirable situation for the [34] E. J. Schwartz, T. Avgerinos, and D. Brumley. Q: attacker. Exploit Hardening Made Easy. In USENIX Security To understand the constraints posed by this, we intro- Symposium, 2011. duce some definitions and naming conventions. idx is the index in Elf Rel.r info that Leakless has computed, [35] H. Shacham. The geometry of innocent flesh on the baseof(x) is the function returning the base address of sec- bone: Return-into-libc without function calls (on the tion x, sizeof(y) is the function returning the size in bytes x86). In Proceedings of the 14th ACM conference of structure y, and is the pointer dereference operator. ∗ on Computer and communications security, pages We define the following variables: 552–561. ACM, 2007. sym = baseof(.dynsym)+idx sizeof(Elf Sym) [36] R. Shapiro, S. Bratus, and S. W. Smith. ”Weird · Machines” in ELF: A Spotlight on the Underappreci- ver = baseof(.gnu.version)+ ated Metadata. In Proceedings of the 7th USENIX +idx sizeof(Elf Verneed) · Conference on Offensive Technologies, WOOT’13, verde f = baseof(.gnu.version r)+ pages 11–11, Berkeley, CA, USA, 2013. USENIX + (ver) sizeof(Elf Verdef) Association. ∗ · [37] L. Szekeres, M. Payer, T. Wei, and D. Song. SoK: To be able to carry on the attack, the following condi- Eternal war in memory. In Security and Privacy tions must hold: (SP), 2013 IEEE Symposium on, pages 48–62. IEEE, 1. sym points to a memory area controlled by the at- 2013. tacker, and 2. one of the following holds: [38] The Avalanche Project. Avalange - a dynamic de- (a) ver points to a memory area containing a zero fect detection tool. https://code.google.com/p/ or a one, or avalanche/. (b) ver points to a memory area controlled by the attacker, which will write a zero value there, or [39] M. Tran, M. Etheridge, T. Bletsch, X. Jiang, V. Freeh, (c) verde f points to a memory area controlled by and P. Ning. On the Expressiveness of Return-into- the attacker, which will place there an appropri- libc Attacks. In Proceedings of the 14th International Elf Verdef Conference on Recent Advances in Intrusion Detec- ately crafted structure. All the other options result in an access to an unmapped tion, RAID’11, pages 121–141, Berlin, Heidelberg, memory area or the failure of the symbol resolution pro- 2011. Springer-Verlag. cess, both of which result in program termination. [40] Ubuntu. Ubuntu Wiki - Security/Features. Leakless is able to satisfy these constraints automatically https://wiki.ubuntu.com/Security/ in most cases. The typical successful situation results in Features#Built as PIE. an idx value that points to a version index with value zero

15 USENIX Association 24th USENIX Security Symposium 657 or one in the .text section (which usually comes after Here, the most difficult case to satisfy is if .dynsym or .gnu.version) and to a symbol in the .data or .bss .gnu.version start at ro start. If we assume that both section. A notable exception, where this is impossible hold true, we can write the following: to achieve, is in the case of small x86-64 ELF binaries idx sizeof(Elf Verneed) < ro end ro start compiled with the support of huge pages [32]. Using huge · − idx sizeof(Elf Sym) rw start ro start pages means that memory pages are aligned to boundaries · ≥ − of 2 MiB and, therefore, the segment containing the read- only sections (in particular, .gnu.version and .text) is Or, alternatively: quite far from the writeable segment (containing .bss and idx sizeof(Elf Verneed) < ro size .data). This makes it hard to find a good value for idx. · idx sizeof(Elf Sym) 2 MiB A.2 The huge page issue · ≥ Knowing that Elf Verneed and Elf Sym have, respec- The effect of huge pages can be seen in the following tively, a size of 2 and 24 bytes for 64 bit ELFs, we can examples: compute the minimum value of ro size to make this sys- $ readelf --wide -l elf-without-huge-pages tem of inequalities satisfiable. The result is 170.7KiB. If

Program Headers: the .rodata section is smaller than this size, an alternative Type VirtAddr MemSiz Flg Align method must be used. ... LOAD 0x00400000 0x006468 R E 0x1000 The second option is to position Elf Verneed in the LOAD 0x00407480 0x0005d0 RW 0x1000 writeable segment. In this case, the attack requirements ... can be described by the following system of inequalities: $ readelf --wide -l elf-with-huge-pages rw start ver < rw end Program Headers: ≤ Type VirtAddr MemSiz Flg Align rw start sym < rw end ... ≤ LOAD 0x00400000 0x00610c R E 0x200000 LOAD 0x00606e10 0x0005d0 RW 0x200000 If we, once again, consider the most stringent constraints ... and apply the previously mentioned assumptions, we get the following: While in the first case the distance between the begin- ning of the executable and the writeable segments is in idx sizeof(Elf Verneed) rw start ro start · ≥ − the order of the kilobytes, with huge pages is more than idx sizeof(Elf Sym) < rw start ro start+ · − 2 MiB, and a valid value for idx cannot be found. +rw size There are two ways to resolve the problems posed to Leakless by small 64-bit binaries. Or, alternatively: The first option is to find a zero value for Elf Verneed in the read-only segment (usually .text). Given ro start, idx sizeof(Elf Verneed) 2 MiB · ≥ ro end and ro size, as the start and end virtual addresses idx sizeof(Elf Sym) < 2 MiB + rw size · and the size of the read-only segment respectively, and rw start, rw end and rw size as the respective values for We can now put a lower bound on the size of the the writeable segment, the following must hold: writeable segment (rw size) to make the system satisfiable: 22MiB. However, this is unreasonably large, and leads ro start ver < ro end us to the conclusion that this approach is not viable with ≤ rw start sym < rw end small 64 bit ELF binaries that use huge pages. ≤

16 658 24th USENIX Security Symposium USENIX Association