Security Evaluation of Apple’s iPhone

Charlie Miller
Jake Honoroff
Joshua Mason

Independent Security Evaluators

{cmiller, jake, josh} AT securityevaluators.com

July 19, 2007

Executive Summary
The Apple iPhone was released to much fanfare on June 29, 2007. Because of the large
amount of personal information stored on these mobile devices, we decided to conduct a secu-
rity analysis of the iPhone. The iPhone's applications for surfing the web and checking emails
are potentially at risk to remote attacks. We wanted to determine exactly how well the software
on the iPhone was designed to resist such attacks.

The iPhone runs a stripped down and customized version of Mac OS X on an ARM processor.
Much of the device's claimed security is reliant on its restrictions against running third party ap-
plications. Only Javascipt code can be executed in the Safari web browser, ensuring that all
such code executes in a “sandbox” environment. Many of the features of Safari have also been
removed, such as the ability to use plug-ins such as Flash. Likewise, many filetypes cannot be
downloaded. These actions serve to reduce the attack surface of the device.

However, there are serious problems with the design and implementation of security on the
iPhone. The most glaring is that all processes of interest run with administrative privileges. This
implies that a compromise of any application gives an attacker full access to the device. Like the
desktop versions of Mac OS X on which its operating system is based, the iPhone also does not
utilize widely accepted practices, such as using address randomization or non-executable
heaps, to make exploitation more difficult. These weaknesses allow for the easy development of
stable exploit code once a vulnerability is discovered.

To demonstrate these security weaknesses, we created an exploit for the Safari browser on the
iPhone. We used an unmodified iPhone to surf to a malicious HTML document that we created.
When this page was viewed, the payload of the exploit forced the iPhone to make an outbound
connection to a server we controlled. The compromised iPhone then sent personal data includ-
ing SMS text messages, contact information, call history, and voice mail information over this
connection. All of this data was collected automatically and surreptitiously. After examination of
the filesystem, it is clear that other personal data such as passwords, emails, and browsing his-
tory could be obtained from the device. We only retrieved some of the personal data but could
just as easily have retrieved any information off the device.

Additionally, we wrote a second exploit that performs physical actions on the phone. When we
viewed a second HTML page in our iPhone, it ran the second exploit payload which forced it to
make a system sound and vibrate the phone for a second. Alternatively, by using other API func-
tions we discovered, the exploit could have dialed phone numbers, sent text messages, or re-
corded audio (as a bugging device) and transmitted it over the network for later collection by a
malicious party.

Apple was notified of these findings, including detailed technical documentation, on July 17th.
While this paper serves to highlight our findings, we will not release the remaining technical de-
tails until August 2nd. This delay is provided in order to give Apple sufficient time to produce
patches so that attackers cannot take advantage of these vulnerabilities.
 terface. This tool, using the same API func-
Introduction tions used by the iTunes player, was able to
After months of anticipation, the iPhone was access the small portion of the filesystem ac-
finally released to long lines of customers on cessible to iTunes. The user of this program
June 29, 2007. Touted by some articles as could navigate through the file system and
the most “successful product introduction of retrieve and place files on the device. The
the 21st century”, we felt it was important to next step was a program developed called
examine this device for its overall security jailbreak. This program modified the iPhone
posture. in such a way that the entire filesystem could
be accessed through the iPhoneInterface ap-
Mobile devices, such as the iPhone, are be- plication. This did have the drawback that
coming ubiquitous in society. Individuals talk syncing was impossible after using the tool.
to their friends, conduct business, shop on- One of the latest developments includes the
line, and listen to music, all from these small ability to activate the phone by only using
portable computers. Some of these devices, AT&T prepaid cards. Only in the last couple
including the iPhone, provide data transmis- of days did this group of researchers develop
sion over cellular communications and also the ability to produce binaries for the iPhone.
through WiFi connections when accessible. At the writing of this document, no one has
These mobile devices are often used in cor- been able to unlock the phone.
porate settings and travel in and out of the
physical building, passing from outside the
firewall into the heart of the protected net- Overall Security Architec-
work of enterprises. People store their ad-
dress books, passwords, email, and other ture
personal data on these devices. For these
reasons, it is important that these devices are The Apple iPhone runs a stripped down ver-
designed and implemented in as secure a sion of the Mac OS X operating system
manner as possible. commonly found on Apple desktops and
servers. The major difference is that it runs
In this paper, we examine the security of the on an ARM processor instead of x86 or Pow-
Apple iPhone. We highlight some strengths erPC processor. ARM processors are com-
in the design and point out some significant mon in mobile devices due to their lower
problems. We demonstrate the security defi- power consumption. The iPhone comes with
ciencies by producing an exploit which takes a version of the Safari web browser called
advantage of a flaw in the MobileSafari appli- MobileSafari. This version of the browser is
cation to gain complete control over the de- very similar to the typical Safari application
vice. and they share much of the same code base.
However, many of the features of Safari have
been removed in MobileSafari. Likewise,
Public Developments MobileMail is the iPhone mail client and is a
Prior to this work, there was a large amount stripped down version of the Mail program
of work by independent researchers in an found on Mac OS X. There are also pro-
effort to access and unlock the iPhone. grams to send SMS text messages, view
Much of this work was reported on the YouTube videos, and check stocks, among
#iphone-dev IRC channel. One of the first others. The iPhone is capable of sending
discoveries was made by a noted researcher and collecting data using the EDGE network
Jon Lech Johansen, known as “DVD Jon”. provided by AT&T wireless. Alternatively, it
He figured out a way to access the WiFi ca- can send data via WiFi connections and also
pabilities of the iPhone without activating it. has Bluetooth capabilities. An iPhone is acti-
Next, a tool was developed called iPhoneIn- vating by communicating with the iTunes
program running on a computer over a USB as discussed in the previous section). By not
connection. This USB connection is also the allowing 3rd party applications, again the
way the iPhone retrieves and syncs data number of opportunities for attackers is di-
from desktop computers, allowing syncing minished.
with Calendars, address books, mail settings,
etc. It also is the mechanism whereby music Unfortunately, once an iPhone application is
and videos can be placed on the iPhone. breached by an attacker, very little prevents
an attacker from obtaining complete control
The security architecture of the iPhone can of the system. All the processes which han-
best be described as one of reducing the at- dle network data run with the effective user id
tack surface. This is accomplished by limit- of 0, i.e. the superuser. This means that a
ing the number of applications on the device compromise of any application gives the abil-
and limiting the functionality of the existing ity to run code in the context of that applica-
applications. The device does not even con- tion which has the highest possible privilege
tain common binaries such as bash, ssh, or level. Additionally, no address randomization
even ls. For an example of the reduced func- was used in by the operating system. This
tionality of the applications actually present, means that each time a process runs, the
consider MobileSafari. On a normal Mac OS stack, heap, and executable code is located
X computer, Safari comes with the ability to at precisely the same spot in memory. This
display Flash, while MobileSafari does not helps attackers write reliable exploit code by
have this capability. Likewise, when down- allowing them to guess the layout of memory
loading archives like dmg or zip files, Safari from run to run of an application and even
will launch the appropriate helper applica- from device to device. Most modern operat-
tions, save them to disk, and then mount or ing systems incorporate some sort of address
uncompress them. MobileSafari simply re- randomization. Additionally, the heap (and
fuses to download these file types. Similar possibly the stack) is executable. Again, this
limitations are placed on MobileMail as many has the effect of making exploit development
attachment types supported on standard Mac easier for an attacker as it allows them to
OS X installs are not supported by Mobile- simply place their code on the heap and jump
Mail. Likewise, the iPhone does not listen on to it once they have control of the program.
any TCP or UDP ports for incoming data. Had these precaution been taken, it would
This reduction of the type of data processed have forced attackers to use more sophisti-
by the device is an effective way to reduce cated methods of exploitation such as return-
the exposure to potential vulnerabilities. to-libc. Therefore, while precautions were
made to reduce the amount of code available
Continuing on this trend of reducing expo- to a remote attacker, once a vulnerability is
sure, the Apple iPhone does not allow third located it is relatively easy for them to suc-
party applications to run on the device. This cessfully exploit and obtain complete control
is accomplished by denying access to the file of the device.
system to the USB connection and not sup-
plying an appropriate SDK. Similarly, a tech- As briefly mentioned above, the iPhone de-
nical difficulty exists in that there is no “tool- signers restricted access to the filesystem on
chain” in which to build applications for Mac the device. While a USB connection to the
OS X running on an ARM processor. That is, device is established for syncing with iTunes,
no compiler exists outside of Apple which can the filesystem cannot be mounted. Even
build applications which would run on the more, the filesystem accessible to iTunes is
iPhone, even if the file could be placed in the chroot’ed such that only a small set of the
file system. (Some of these considerations filesystem is visible over this connection.
have been changed by the progress of re- This set of the filesystem does not include
searchers attempting to open these devices, the binaries or libraries available. This lim-
ited access to the filesystem doesn’t particu-
larly serve a security role from the perspec- Vulnerability Analysis
tive of a remote attacker. Instead, this serves In order to find vulnerabilities on the iPhone,
as an example of design intended to protect a few options are available to a researcher.
the exclusivity of the iPhone to AT&T. If more Using jailbreak and iPhoneInterface, the bi-
thought had gone into protecting the applica- naries can be extracted from the device and
tions from remote attack and less on prevent- statically analyzed, using a disassembler.
ing the unlocking of the device, the overall Additionally, since the MobileSafari and Mo-
security of the device might have been im- bileMail applications are based on the open
proved. source WebKit project, a source code audit of
that package can be performed. Finally, dy-
namic analysis, or fuzzing, can be executed
Suggested Improvements against the device. This involves sending
The security design of the Apple iPhone con- malformed data to the device in an effort to
centrates all of its defenses on reducing the cause a fault and make it crash. Such fuzz-
device’s expose to vulnerabilities. However, ing can be performed against applications
it does not provide any defense once an at- such as MobileSafari or against the WiFi or
tack has occurred. We recommend using a BlueTooth stack.
layered approach to security. Based on the
findings of the security design and implemen- The vulnerability we discovered and exploited
tation of the device discovered, we recom- was found in MobileSafari using fuzzing.
mend the following changes to be made to
the iPhone.
Attack Scenarios
• Install applications such that they run as an There are at least a couple of vectors
unprivileged user. This would result in a whereby a MobileSafari exploit can be used
successful attacker only gaining the rights against the iPhone. The first is via email. A
of this unprivileged user. link to a malicious site can be included in an
email sent to the victim. When the victim
• chroot the applications such that they can clicks the link, they will be taken to the web-
not access the personal data needed ex- server containing the malicious HTML and
clusively by the other applications. For ex- the exploit will take control of their device.
ample, MobileSafari would not have access
to email or SMS messages. Likewise, Mo- A more subtle approach involves a man in
bileMail would not have access to browsing the middle attack. An attacker could set up
history. and advertise a free WiFi hotspot in a heavily
populated area. The iPhone will automati-
• Add heap and stack address randomiza- cally seek these out and ask the user to con-
tion. This will serve to make the develop- nect to them. Once connected, all traffic from
ment of exploits for vulnerabilities more dif- the victim will pass through the attacker con-
ficult. trolled wireless router. The attacker can in-
tercept and change any HTTP traffic intended
• Use a memory protection scheme such that for the victim. This traffic can invisibly be
no memory pages are both writable and modified to contain the iPhone exploit code.
executable. Again, this serves to make ex- Again, complete control will be obtained over
ploit development much more difficult. the iPhone. This time the only actions per-
formed by the victim include using an unsafe
WiFi connection and surfing to any website.
This last scenario is aided by the fact that
iPhones advertise their existence via HTTP
headers. In this manner the exploit code can files, it can correctly access the virtual mem-
be delivered only to iPhones and not other ory contained within it. Between the crash
devices and browsers. reports and the core files, a complete snap-
shot of the the application when it crashed is
A similar attack can occur if an attacker con- obtained.
trols the DNS used by an iPhone user. In this
case, the attacker can point the iPhone to the In order to obtain data from the application
page containing the exploit whenever the the when it wasn’t crashing, such as at a particu-
iPhone attempts to go to a new page. This lar instruction of interest, we needed to mod-
method of attack requires no interaction from ify the application. To do this, we first ob-
the user, only that they are using the web tained the application being exploited off the
browser. iPhone filesystem, using iPhoneInterface.
We then disassembled it, and modified it
such that it would crash at the instruction we
Blackbox Exploitation wanted to investigate. For example, we
Once a vulnerability has been identified, the could modify the instruction to set the pro-
next step is developing a functioning exploit. gram counter to zero at that time. Placing
This is very difficult for a device such as the the binary back on the iPhone, sending data
iPhone since there is no way to run a debug- to it, and finally collecting the crash report
ger against the target application in order to and core file, gave all the information
view memory and discover the way the exe- needed. While tedious, this technique was
cution flows in the application. However, in effective.
this case we were able to utilize the Mac OS
X crash reporter. This daemon runs and Of course, this is a far cry from having a de-
monitors any programs for crashes. When bugger on the system, but it was enough to
one is detected it records a log of the crash, successfully develop a successful attack
including relevant register values. These re- against this platform. Had the addresses
ports can then be transported to a desktop been randomized, it would have made a hard
computer when syncing. The crash reports job even more difficult.
can also be downloaded directly off the
iPhone using jailbreak and iPhoneInterface.
Blackbox Shellcode De-
While the CrashReporter provides register
values and basic memory mapping informa-
velopment
tion, it does not include direct access to the In order to generate valid opcodes for the
memory. In order to obtain this crucial infor- iPhone, we first installed a Linux x86 to ARM
mation, it is possible to modify the iPhone in cross compiler. This would compile our ARM
such a way that the applications will dump assembly to bytecode which we could then
core files when they crash. This is accom- extract into shellcode.
plished by adding the file /etc/lauchd.conf
Besides not having a debugger, developing
containing the line
iPhone shellcode also presented other chal-
limit core unlimited lenges. Since we didn’t have access to an
ARM processor with a debugger, we had ab-
to the iPhone using iPhoneInterface. Core solutely no real way to test the shellcode be-
files can be retrieved off the iPhone from the sides trying it and using the core files ob-
/cores directory, again using iPhoneInterface. tained. This greatly increased our develop-
These core files can be read by a debugger ment time.
like gdb. While standard gdb cannot display
the context information contained in the core
 DTrace to be included in Next Mac OS X:
Vulnerability Details http://sun.systemnews.com/articles/102/2/ne
This section is temporarily omitted. Full de- ws/16842
tails will be released on August 2nd. This
delay is provided so that Apple has time to OS X Heap Exploitation Techniques
develop appropriate patches to mitigate http://felinemenace.org/papers/p63-0x05_OS
these vulnerabilities. X_Heap_Exploitation_Technqiues.txt

Conclusions Hack a Mac, get $10,000

http://news.com.com/8301-10784_3-9710845
Due to the widespread attention paid to the
-7.html
iPhone and the security implications of mo-
bile devices in general, we performed a secu-
Safari for Windows: Released and hacked in
rity evaluation of the new Apple iPhone.
a day
While Apple takes some precautions to mini-
http://www.infoworld.com/article/07/06/11/Saf
mize the amount of code accessible to re-
ari-for-Windows-released-and-hacked-in-a-da
mote attackers, it did not take other basic
y_1.html
precautions in designing a robust security
solution for the device. While made more With Windows port, a bug-hunting Safari for
difficult due to the closed nature of the de- Apple
vice, with little effort we were able to find a http://www.infoworld.com/article/07/06/12/Wit
vulnerability in the iPhone. We were then h-Windows-port-a-bug-hunting-Safari-for-App
able to leverage this vulnerability and use it le_1.html
to write an exploit which could extract per-
sonal information off the device without the Mac OS X PPC Shellcode Tricks
user ever knowing. http://uninformed.org/?v=1&a=1&t=pdf

Acknowledgments Building and Testing gcc/glibc cross tool-

chains http://www.kegel.com/crosstool/
We’d like to thank the ISE management for
allowing us some time to look at these de- “Into my ARMS” Developing StrongArm/Linux
vices. We’d also like to thank some of our shellcode
coworkers for their help on this project: Sam http://isec.pl/papers/into_my_arms_dsls.pdf
Small, Adam Stubblefield, and Matt Green.
Main Page - The iPhone Dev Wiki
http://iphone.fiveforty.net/wiki/index.php?title=
References Main_Page
Mac OS X internals: A Systems Approach,
Amit Singh, Addison Wesley, 2006

Mac OS X Debugging Magic:

http://developer.apple.com/technotes/tn2004/
tn2124.html

CrashReporter:
http://developer.apple.com/technotes/tn2004/
tn2123.html