Rixstep
	`About \| ACP \| Buy \| Industry Watch \| Learning Curve \| News \| Products \| Search \| Substack`

Home » Industry Watch

iPhone Hacked

Get It

Try It

The Apple iPhone has been hacked. It has been possible to inject malicious code into the 'MobileSafari' web browser present on the device and command it to send sensitive data to a remote unauthenticated destination.

Apple have been informed and the full details of the exploit will be made available on 2 August 2007 at Black Hat.

It took but a fortnight.

iPhone Security Architecture

The research team based at amongst other places Johns Hopkins University and consisting of Charlie Miller, Jake Honoroff, Joshua Mason, Matt Green, Avi Rubin, Sam Small, and Adam Stubblefield and working under the moniker Independent Security Evaluators have both good things and not so good things to say about the Apple device in terms of security.

The most positive aspect of iPhone security is minimising the potential attack vectors. OS X is a slimmed down version of the operating system used on Apple computers and as such not only saves disk space but reduces the possible exploit targets. No shells are available and the traditional 'bins' are all but empty.

The most negative aspect is of course the way ordinary 'user land' applications are either owned by or allowed to run as root. This means - as explained at this site previously - that (in typical MS Windows fashion) as soon as attackers break through the outer perimeter they own the machine.

'Once an iPhone application is breached by an attacker, very little prevents an attacker from obtaining complete control of the system. All the processes which handle network data run with the effective user ID of 0, ie the superuser. This means that a compromise of any application gives the ability to run code in the context of that application which has the highest possible privilege level.'

The researchers also note load addresses are not randomised and heaps are not flagged as non-executable.

'No address randomisation is used in by the operating system. This means each time a process runs, the stack, heap, and executable code are located at precisely the same spot in memory.' 'This helps attackers write reliable exploit code by allowing them to guess the layout of memory from run to run of an application and even from device to device.' 'Additionally the heap (and possibly the stack) are executable. This has the effect of making exploit development easier for attackers as it allows them to simply place their code on the heap and jump to it once they have control of the program.'

Conclusions

The researchers don't think iPhone users need to toss out their devices but there are issues to be addressed.

'Almost all of the security effort on the iPhone seems to have been spent protecting the revenue model, rather than protecting the user.' 'Therefore while precautions were made to reduce the amount of code available to a remote attacker, once a vulnerability is located it is relatively easy for them to successfully exploit and obtain complete control of the device.'

The team offer four suggestions.

Don't run user land code as root. Apple still have not explained why they deemed this necessary although several iPhone users report having submitted this issue as a 'bug' and having been given official 'ticket numbers'.
'chroot' user land code. This to prevent ordinary applications from accessing each other's data.
Add stack and heap address randomisation. This to thwart attempts to create 'cookie cutter code'.
Page frames never both writable and executable. This for obvious reasons.

Apple Notified

Apple have been notified of the exploit on 17 July and have acknowledged receipt of the information. Details of the exploit are not yet released to give Apple time to plug the hole.

Further Information

Further information including a white paper and a movie demo of the exploit are available at the Exploiting iPhone website.

Thanks to Devon at Pixel Groovy for the excellent artwork.