iPhone OS X Architecture: Disk, Shell, and Password Security
July 14th, 2007
Daniel Eran Dilger
Continuing on the series looking at the architecture of the iPhone, here’s a look at what’s been discovered about the security in the core OS of the iPhone.
[Leopard, Vista and the iPhone OS X Architecture]
[iPhone OS X Architecture: the Mach Kernel and RAM]
[iPhone OS X Architecture: the BSD Unix Userland]
[iPhone OS X Architecture: Cocoa Frameworks and Mobile Mac Apps]
Tampering with the Kernel’s Secret Recipe.
There are two disk images that iTunes copies to the iPhone during a software restore session. These DMG files have been extracted and are the reason why crackers have been able to list the files on the phone. Looking at these DMGs is analogous to looking at the contents of a Mac OS X installer DVD.
So far, there has been little significant progress in getting a modified copy of the iPhone’s software installed. That’s because the kernel’s secret recipe is locked down in a fortified bunker, and it refuses to talk to any software that isn’t signed with Apple’s private key.
The kernel is not part of the software image that crackers have been looking at. Instead, it sits on its own encrypted disk image, which appears to require massive brute force efforts to decrypt. If it is ever unlocked, it will likely have to involve a workaround crack, because it is scrambled with a long enough key that makes simply guessing the password virtually impossible.
The iPhone loads its encrypted kernel image into RAM and boots from it, and it in turn loads the userland disk image where all of the other files sit. Because the kernel is locked, it can’t be modified or even examined. Because it is secured, it can demand that any disk image it talks to is also secured.
If crackers change the disk image software–by adding or significantly modifying an iPhone app, for example–it will no longer match the digital signature, and the kernel will refuse to load it.
Root Password Hacked?
The iPhone’s “root” and “user” passwords that were discovered are simply used by the running OS X system on the phone. There is no need for multiple user accounts on the iPhone, but OS X uses the inherently multiuser architecture of Unix and Mac OS X to separate system processes running as “root” and user processes running as a generic user.
These passwords are stored in BSD flat files, and are easy to obtain by looking at the restore disk image files. While “iPhone root passwords hacked!” makes a good headline, it was a meaningless statement as those passwords don’t really provide any access to anything.
Because the iPhone doesn’t offer remote command line access or even a local terminal shell, and does not listen or respond to any TCP port traffic, nothing can be done with the passwords.
Contrast this to the Apple TV, where knowing the user password made accessing the device and loading new software easy.
The Fully Interactive Shell!
The second big iPhone headline involved rigging up serial console access to directly talk to the iPhone hardware. This was presented as “full console access to an interactive shell,” which when translated means “we can bounce commands and get a listing of options back.”
Rather than gaining console shell access similar to the Mac OS X terminal however, crackers were really discovering the iPhone’s bootloader. Like Intel Mac’s EFI and PowerPC Mac’s OpenFirmware, the iPhone has a fairly sophisticated system for obtaining a disk image, identifying the operating system to load, setting up a boot environment, and then starting the operating system.
On a PC, this is done by the far simpler BIOS, which actually does very little, and requires helper apps to load an alternative OS. Why would a PC need to load an alternative to Windows? Oh, right, there is Linux. Because many crackers are more familiar with the basics of a PC, they likely jumped to conclusions on finding a sophisticated bootloader, and thought they had real and useful access to something.
Instead, they later found themselves stuck at simply making requests that the bootloader denied. Because it only loads signed software, it’s rather difficult to get files onto the iPhone, let alone run them.
Running as Root.
Some have criticized Apple’s use of the root account on the iPhone, because running processes as root in a desktop environment opens the potential for security attacks to gain full access to the system, rather than only assuming control of the limited privileges of the process they exploited.
However, there are few ways to feed the iPhone any malicious code that could do anything, making this criticism ring hollow. Copying files into the iPhone via the software install process Apple uses with iTunes is blocked by code signing requirements, and it’s hard to figure out how one might get anything on it otherwise:
• There’s currently no way to put the iPhone into disk mode.
• There’s currently no Bluetooth support for OBEX file transfers.
• There’s no way to download files using Safari or other Internet applications.
[Update: A number of readers pointed out Ecamm’s iPhoneDrive software, designed to allow users to copy files to and from an iPhone. This does work like the iPod’s disk mode, but nothing that it copies to the iPhone is recognized by the iPhone’s OS X, nor can it be run or viewed by the iPhone, so it has no impact on security.]
The ARM Holding Up iPhone’s Security Breeches.
The only security vulnerabilities that can be easily imagined are:
• Exploiting a Safari HTML rendering bug to take over control of the browser and inject executable code. The problem is that Safari crashes and is wiped out and restarted whenever anything seems to bother it, and injecting ARM-specific exploits into an unknown system would be tricky.
• Exploiting graphic or HTML rendering within Mail to take over and inject executable code. This faces the same barriers as those noted for Safari.
iPhone vs Windows on Security.
Will the iPhone’s email and web services end up in the same boat as Microsoft’s Windows, if the iPhone grabs a large share of the market?
Despite what a variety of security outfits are paid to say, security problems are not the result of dominant market share. The iPod and the PlayStation weren’t infected by viruses or worms, for example.
The reason Microsoft’s Outlook was so easily exploited and used as the mechanism for delivering the devastating outbreaks of viruses and worms that plagued IT over the last several years was that it was specifically designed to run code, including scripts written for Microsoft’s Visual Basic for Applications.
Outlook would happily execute code in email attachments, and would jump at the opportunity to use VBA to give the malicious script a list of the user’s entire contact list, and set up the perfect environment to rapidly propagate such malware. The problem wasn’t email, it was Microsoft’s security-agnostic implementation.
Internet Explorer was similarly designed to automatically run programs embedded in webpages using Microsoft’s own ActiveX architecture. This was similarly exploited to kick off programatic mayhem without the user even knowing they had triggered the minefield of booby traps Bill Gates had engineered for them.
Consider the Source.
Windows was riddled with ways to talk to it, remotely control and configure it, kick off scripts, and launch applications. There was little regard for security until those mechanisms–originally designed to work within a private office network that was assumed to be secure–started getting attacked by crackers who discovered an adware/spyware business model behind exploiting its naivety.
The iPhone shares nothing in common with Windows. It’s currently not designed to allow any development, it does not currently listen for any network traffic, and it was engineered with strong security in mind.
That makes it particularly laughable that Gartner’s Ken Dulaney complained that the iPhone “didn’t have a firewall.” He quite clearly was talking beyond his knowledge and understanding, and now looks like quite the fool.
Dulaney, along with Rob Enderle and the other paid Windows Enthusiasts, don’t seem to know and certainly don’t want to admit knowing that Windows is not exactly a shining example of engineering. It must be very embarrassing to have the curtain pulled back to reveal the absolute incompetence they have been cheerleading throughout their careers.
How Things Might Change.
The existing iPhone software was delivered to get the iPhone released on time. It has placeholders sitting in a number of spots that will open potential security vectors as they are fleshed out more completely. That’s no doubt one of the reasons that new features are being rolled out incrementally, rather than having been thrown out in an unfinished beta.
There is no question that Bluetooth will gain far more sophistication that it currently has. It’s currently only being used as a headset link, so if you don’t use a headset, you can save battery life by turning Bluetooth off. In the future, it will undoubtedly add support for wireless headphones, car integration, and connecting to other devices, perhaps including GPS, although there are other options. Another article will look closer at Bluetooth.
The iPhone has a mere chalk outline of Bonjour support. This is a key technology for Apple, and offers a huge amount of potential. A future article will look at Bonjour’s potential on the iPhone.
New networking services. The iPhone is running BSD, which many security experts and crackers are intimately familiar with, despite the fact that it has been ported to ARM. As Apple opens up the iPhone’s networking capabilities, it will have to observe security precautions in order to prevent inadvertently allowing access inside its system. The next article will give an overview of the iPhone’s BSD Unix userland above the kernel: iPhone OS X Architecture: the BSD Unix Userland.
Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast! Submit to Reddit or Slashdot, or consider making a small donation supporting this site. Thanks!