Penetration Test Report (TrailOfBits): Trail of Bits   Apple iOS 4

Trail of Bits
Apple iOS 4 Security Evaluation
Dino A. Dai Zovi
Principal
Trail of Bits LLC
Version: 1.0
Trail of Bits
Table of Contents
ASLR 1
1
Overview
3
Assessment
Code Signing 4
4
Mandatory Code Signing
11
Code Signing Enforcement
11
AppleMobileFileIntegrity
13
Dynamic Code Signing
14
Assessment
Sandboxing 15
15
Introduction
15
Application Containers
15
Sandbox Profiles
22
Assessment
Data Encryption 24
24
Overview
24
Hardware Encryption
Apple iOS Security Evaluation i
Trail of Bits
25
Data Protection API
25
Filesystem Encryption
26
iOS Passcodes
27
Data Protection API Coverage
29
Assessment
Apple iOS Security Evaluation ii
Trail of Bits
ASLR
Overview
Address Space Layout Randomization (ASLR) is an important protection that makes the remote exploitation of memory
corruption vulnerabilities significantly more difficult. In particular, when it is fully applied, it usually requires that attackers
find and exploit one or more memory disclosure vulnerabilities in order to enable the exploitation of a memory corruption
vulnerability. On many operating systems, however, the implementation of ASLR may be incomplete and attackers can
make often make use of executable or writable memory regions at fixed or predictable locations.
ASLR was introduced in iOS 4.3 and there are two levels of completeness of ASLR in iOS 4.3, depending on whether the
application was compiled with support for Position Independent Executables (PIE). If the application was compiled
without PIE support, it will run with limited ASLR. Specifically, the main executable binary (including its code and data
sections) and the dynamic linker (dyld) will be loaded at fixed locations. The main thread’s stack will also always begin at
the same location in memory. This is presumably to maintain compatibility with existing iOS applications. If the application
is compiled with PIE support, then the application will be able to make full use of ASLR and all memory regions will be
randomized. In iOS 4.3, all built-in applications are compatible with full ASLR. The table below summarizes which
segments of memory will be found at randomized locations depending on whether the application was compiled with or
without PIE support.
Memory Region Randomization by Deployment Target Version
PIE Executable Data Heap Stack Libraries Linker
No Fixed Fixed Randomized Fixed Randomized Fixed
per execution per device boot
Yes Randomized Randomized Randomized Randomized Randomized Randomized
per execution per execution per execution per execution per device boot per execution
(more entropy)
Apple iOS Security Evaluation 1
Trail of Bits
Observing ASLR
In order to detect which memory regions are loaded at randomized locations and how often that location changes, a
small command-line executable1 was written to observe and output a memory address within those regions. The
program captures the memory addresses of the executable’s main function, a variable in its initialized data segment, a
variable in its uninitialized data segment, a single heap allocation, a variable on the stack, the address of a function in a
loaded shared library, and the load address of the dynamic linker (dyld). This program was used to observe memory
addresses for five invocations before rebooting the device and gathering data from five more invocations. This was
performed for the executable compiled with and without support for Position Independent Executables (PIE). The results
of these tests are shown in the table below.
Observed Memory Addresses
Main Executable Heap Stack Libraries Linker
0x2e88 0x15ea70 0x2fdff2c0 0x36adadd1 0x2fe00000
0x2e88 0x11cc60 0x2fdff2c0 0x36adadd1 0x2fe00000
0x2e88 0x14e190 0x2fdff2c0 0x36adadd1 0x2fe00000
0x2e88 0x145860 0x2fdff2c0 0x36adadd1 0x2fe00000
0x2e88 0x134440 0x2fdff2c0 0x36adadd1 0x2fe00000
RRRRReeeeebbbbboooooooooottttt
0x2e88 0x174980 0x2fdff2c0 0x35e3edd1 0x2fe00000
0x2e88 0x13ca60 0x2fdff2c0 0x35e3edd1 0x2fe00000
0x2e88 0x163540 0x2fdff2c0 0x35e3edd1 0x2fe00000
0x2e88 0x136970 0x2fdff2c0 0x35e3edd1 0x2fe00000
0x2e88 0x177e30 0x2fdff2c0 0x35e3edd1 0x2fe00000
CCCCCooooommmmmpppppiiiiillllleeeee wwwwwiiiiittttthhhhh -----fffffPPPPPIIIIIEEEEE
0xd2e48 0x1cd76660 0x2fecf2a8 0x35e3edd1 0x2fed0000
0xaae48 0x1ed68950 0x2fea72a8 0x35e3edd1 0x2fea8000
0xbbe48 0x1cd09370 0x2feb82a8 0x35e3edd1 0x2feb9000
0x46e48 0x1fd36b80 0x2fe432a8 0x35e3edd1 0x2fe44000
0xc1e48 0x1dd81970 0x2febe2a8 0x35e3edd1 0x2febf000
RRRRReeeeebbbbboooooooooottttt
0x14e48 0x1dd26640 0x2fe112a8 0x36146dd1 0x2fe12000
0x62e48 0x1dd49240 0x2fe112a8 0x36146dd1 0x2fe60000
0x9ee48 0x1d577490 0x2fe9b2a8 0x36146dd1 0x2fe9c000
0xa0e48 0x1e506130 0x2fe9d2a8 0x36146dd1 0x2fe9e000
0xcde48 0x1fd1d130 0x2feca2a8 0x36146dd1 0x2fecb000
The memory addresses shown in the table above clearly show which memory regions are randomized and how often for
both non-PIE and PIE executables. It also shows that the amount of entropy in heap memory randomization is greater for
PIE executables than for non-PIE executables. In this way, the PIE compatibility of an executable can be used to
determine its level of ASLR compatibility in iOS 4.3: limited or full.
1 Included in the supplementary materials as src/aslr/aslr.c
Apple iOS Security Evaluation 2
Trail of Bits
Third-Party Applications
In order to determine the prevalence of PIE support in third-party applications, the top ten free applications as of the time
of this writing were downloaded and examined. As summarized in the table below, none of these applications were
compiled with PIE support.
PIE Support in Top Ten Free Applications
Application Version Post Date PIE
Songify 1.0.1 June 29, 2011 No
Happy Theme Park 1.0 June 29, 2011 No
Cave Bowling 1.10 June 21, 2011 No
Movie-Quiz Lite 1.3.2 May 31, 2011 No
Spotify 0.4.14 July 6, 2011 No
Make-Up Girls 1.0 July 5, 2011 No
Racing Penguin, Flying Free 1.2 July 6, 2011 No
ICEE Maker 1.01 June 28, 2011 No
Cracked Screen 1.0 June 24, 2011 No
Facebook 3.4.3 June 29, 2011 No
Xcode Automatic Deployment Target
In Xcode, the “iOS Deployment Target” application setting is the lowest version of iOS that the application will run on. The
default setting is “Compiler Default”, indicating that Xcode will automatically choose the minimum version of iOS based
on the APIs that are used by the application. This may cause more applications to automatically support PIE if they use
an API that is only available in iOS 4.3 or later. More likely, however, is that applications that make use of new APIs
introduced in the upcoming release of iOS 5 will automatically be compiled with PIE support.
Assessment
In order to preserve application compatibility, applications compiled without PIE support do not run with full ASLR on iOS
4.3. This leaves both the application and dynamic linker text segments at fixed known locations. The presence of known
code sequences at known locations facilities the use of code reuse techniques such as return-oriented programming in
the exploitation of memory corruption vulnerabilities. The most likely targets for remote exploits, however, are the built-in
MobileSafari and MobileMail applications, which are both compiled with PIE support and make use of full ASLR in iOS
4.3.
Scriptable applications such as MobileSafari, provide more opportunities for an attacker to identify and exploit memory
disclosure vulnerabilities that may be used to weaken or defeat the randomization provided by ASLR. Other applications
that do not provide malicious content as many opportunities to inspect their runtime environment and adapt to it are
significantly more difficult to remotely exploit. The presence of full ASLR, especially in combination with the other runtime
protections described in this document such as Code Signing Enforcement and Sandboxing, makes the remote
exploitation of memory corruption vulnerabilities in iOS applications significantly more difficult than on other mobile or
desktop platforms.
Apple iOS Security Evaluation 3
Trail of Bits
Code Signing
Mandatory Code Signing