iPhone Hack: Security Lessons Learned

In their paper "Security Evaluation of Apple’s iPhone," Charlie Miller, Jake Honoroff and Joshua Mason present an overview of how they were able to compromise an iPhone. Embedded developers should pay special attention to a key point they bring up: that all of the iPhone’s processes of interest run with administrative privileges, giving an attacker full access to the device. The trio also notes that the iPhone runs a stripped-down and customized version of Mac OS X. But this version still has access right restrictions. And Apple did in fact force some restrictions. For example, only Javascipt code can be executed in the Safari web browser and many filetypes cannot be downloaded. But why forego additional restrictions? These days, security issues often take a back seat to features when developing an embedded system. And such systems are almost always networked, whether via a cell tower or an Ethernet connection. The iPhone exploit used a simple web browser fault to gain access to the system. Different approaches would be required for the typical embedded device but the idea is still the same: find a hole and exploit it. There are few systems that do not have at least one hole, but here are some ways iPhone designers—as well as designers in general—can ensure the security of their devices. One approach to preventing iPhone exploitation is to layer security and have a depth of more than two. It appears that the iPhone had a single level—the Javascript sandbox. Simply splitting parts of the system into root and user mode would have added another layer. The use of a virtual machine architecture could add even more security. Many security measures require additional hardware support so the choice of the underlying platform is key to the level of security that can be implemented. Still, even limited security measures like the ability to restrict flash programming can keep an attacker from completely overtaking a system. Finally, designers shouldn’t confuse digital rights management (DRM) or secure communications with system security. Though they use many of the same encryption techniques, DRM is designed to allow a content provider control over what the user may do, and secure communications ensure that the data flowing between systems will not be changed or acquired. The iPhone had both, and obviously these features had nothing to do with prevention of this exploit. The iPhone is currently a closed platform, so Apple will have to fix this particular problem. But it is likely to be only the first of many, since it’s a popular item and thus a target of attack. I’ve never been a fan of security through obscurity anyway.