Address Space Randomization for Mobile Devices

Address Space Randomization for Mobile Devices Hristo Bojinov Dan Boneh Rich Cannings Stanford University Stanford University Google, Inc. Stanford, CA, USA Stanford, CA, USA Mountain View, CA, USA [email protected] [email protected] [email protected] Iliyan Malchev Google, Inc. Mountain View, CA, USA [email protected] ABSTRACT [19]. ASLR randomizes the base points of the stack, heap, Address Space Layout Randomization (ASLR) is a defen- shared libraries, and base executables. The goal of ASLR sive technique supported by many desktop and server oper- is to make certain classes of control-hijacking attacks more ating systems. While smartphone vendors wish to make it difficult: with executable code residing at unknown loca- available on their platforms, there are technical challenges tions, garden variety buffer or stack overflow attacks are in implementing ASLR on these devices. Pre-linking, lim- made significantly harder to develop and execute [14]. In ited processing power and restrictive update processes make conjunction with OS mechanisms that only allow writing it difficult to use existing ASLR implementation strategies to non-executable memory (e.g. DEP in Windows), ASLR even on the latest generation of smartphones. In this paper prevents many network-based native code control hijacking we introduce retouching, a mechanism for executable ASLR attacks from completing [24]. that requires no kernel modifications and is suitable for mobile devices. We have implemented ASLR for the Android Implementation challenges. operating system and evaluated its effectiveness and per- Although there has been much work on implementing and formance. In addition, we introduce crash stack analysis, evaluating ASLR for general-purpose PCs, none of the ma- a technique that uses crash reports locally on the device, jor smartphones currently use it. In principle, the same or in aggregate in the cloud to reliably detect attempts to ASLR techniques should carry over to mobile devices, how- brute-force ASLR protection. We expect that retouching ever there are several practical obstacles that make this dif- and crash stack analysis will become standard techniques in ficult. Smartphone operating systems spend considerable mobile ASLR implementations. effort to minimize boot and application launch time, power consumption, and memory footprint. These optimizations make existing ASLR implementation strategies insufficient. Categories and Subject Descriptors We give two examples for challenges in implementing ASLR D.4.6 [Operating Systems]: Security and Protection in Android: • The Android OS prelinks shared libraries to speed up General Terms the boot process. Prelinking takes place during the Security, Experimentation, Performance build process and results in hard-coded memory ad- dresses written in the library code. This prevents relo- cating these libraries in process memory. Android also Keywords uses a custom dynamic linker that cannot self-relocate ASLR, control flow hijacking, return-to-libc, mobile devices, at run-time (unlike ld.so). Recent attack techniques smartphones, Android against ASLR clearly demonstrate the need to randomize the whole process address space, including base 1. INTRODUCTION executables and shared libraries [18]. Over the last few years Address-Space Layout Random- • During normal operation the filesystem on the device is ization (ASLR) has become mainstream, with various lev- mounted read-only for security reasons. This prevents els of support in Linux [25], Windows [20], and Mac OS X binary editing tools [12] from modifying images on the device or in file-backed memory. Permission to make digital or hard copies of all or part of this work for Our contributions. personal or classroom use is granted without fee provided that copies are We propose retouching, a novel mechanism for randomiz- not made or distributed for profit or commercial advantage and that copies ing prelinked code for deployment on mobile devices. Re- bear this notice and the full citation on the first page. To copy otherwise, to touching can randomize all executable code including li- republish, to post on servers or to redistribute to lists, requires prior specific braries (and prelinked libraries), base executables, and the permission and/or a fee. WiSec’11, June14–17, 2011, Hamburg, Germany. linker. Unlike traditional ASLR implementations, retouch- Copyright 2011 ACM 978-1-4503-0692-8/11/06 ...$10.00. ing requires no kernel modifications. We implement the mechanism for Android, evaluate its effectiveness, and mea- 2.2 Windows sure its impact on performance at build and runtime and on Following the implementation of DEP (Data Execution memory footprint. Our conclusion is that retouching is an Prevention: marking the stack and heap as non-execute) in effective approach to ASLR and is particularly well-suited Windows XP SP2, Microsoft implemented ASLR in Win- in situations where performance is an issue, or when there dows Vista. The two mechanisms work together to pre- are incentives to avoid kernel changes. vent control-flow hijacking attacks (such as return-to-libc), Our second contribution is a cloud-based approach to de- as well as injected code from being executed on the stack tecting and preventing ASLR brute-forcing [23]. We intro- or heap. In the Windows ASLR implementation, executable duce crash stack analysis, a technique that analyzes crash code randomization happens on every reboot, when a global reports from mobile devices and reliably detects attempts image offset is selected randomly out of 256 possibilities. to bypass ASLR by guessing the random offset used on each Additionally, every process is launched with an individually device. We evaluate crash stack analysis using real crash randomized stack, heap, and Process Environment Block data as well as simulated attacks, and conclude that the ap- (PEB) [26]. The 8 bits of entropy used for selecting the off- proach can effectively detect attacks and, in addition, can sets renders the Windows ASLR implementation vulnerable help pinpoint the OS code being targeted. to guessing attacks [23], but is still better than no random- Brute forcing mobile ASLR can be very effective and dif- ization at all. ficult to detect locally. By making a single attempt on every Adopting the Windows ASLR approach directly in An- mobile user the attacker can compromise 1=256 of mobile droid would increase boot time of the device substantially devices (assuming 8 bits for ASLR randomness as in Win- by eliminating library prelinking. dows). Given the billions of phones in use, this fraction gives 2.3 Mac OS X the attacker control of a large number of devices. Apple introduced ASLR in the Leopard release of Mac OS In the rest of the paper, Sections 2 and 3 give some back- X. Currently, OS X only randomizes the offsets of shared ground information on ASLR and the Android OS, Section libraries. This randomization is performed at the time li- 4 presents the threat model that we address with our de- braries are prelinked, effectively prelinking them at a dif- sign and implementation in Section 5. Section 6 evaluates ferent address on each system. In addition to ASLR, the the implementation and discusses it in the context of other operating system protects stack and heap data from being related and future work. Section 7 introduces crash stack executed (heap protection is only available for 64-bit bina- analysis and evaluates its effectiveness. Sections 8 and 9 ries) [19, 15]. discuss future and related work, and Section 10 concludes. Retouching, the technique we have developed, is concep- tually similar to randomization during prelinking. The addi- 2. OVERVIEW OF ADDRESS-SPACE RAN- tional benefits of retouching are in significantly reducing the DOMIZATION amount of work performed on the target device by perform- ing the prelinking during the build process and retaining the Before discussing our system we first survey traditional minimum information needed for randomization. Addition- strategies for implementing ASLR and their limitations on ally, no ELF manipulation code needs to be installed on the Android. The first ASLR implementation, PaX [25], was target. designed for Linux. Subsequently, ASLR was implemented in Windows Vista and Mac OS X. We briefly describe these 3. OVERVIEW OF ANDROID implementations focusing primarily on user-space randomization (as opposed to kernel randomization, which is a sep- Android [1] is an operating system for mobile devices de- arate topic). veloped by Google, Inc. While Android borrows much plat- form code from other open-source operating systems, its se- 2.1 PaX curity model was built from the start with the assumption PaX implements ASLR by generating three different ran- that the device will be running a variety of untrusted (or dom offsets (delta values) that apply to different areas of the partially trusted) applications. A manifestation of this ap- address space: proach is the execution of each installed application in a sep- arate process running under a unique user identifier (UID): • delta mmap controls the randomization of areas allo- any damage that the application can cause will be contained cated via mmap(), which includes shared libraries, as within the resources that are dedicated to this UID|disjoint well as the main executable when compiled and linked from those of any other UID or application. as an ET DYN ELF file Android is built on top of the Linux kernel. The system includes many device drivers and native system libraries, in- • delta exec is the offset of the base executable, fol- cluding a customized implementation of libc. Applications lowed by the heap, when the base executable is of type in Android are written in Java and execute in a virtual ma- ET EXEC (not position-independent) chine called Dalvik, in the form of Dalvik bytecode. After • delta stack is the offset for the user-space stack boot, the system runs many services (such as the media service, telephony service) each in its own process and having PaX ASLR is complemented by data and stack execution a unique UID.

Load more