Next article: Tales from the Sausage Factory: Why Those Big Downloads for Simple Updates?
Previous article: Performance Comparisons of Common Operations, iPhone Edition
Tags: iphone rant
In part two of my potentially ongoing series about the iPhone SDK, I want to discuss the platform's potential for malware.
As I discussed previously, an iPhone (or iPod Touch) will not run any software that has not been signed by Apple. Obviously there are ways around this, but I want to focus on the official firmware. Behind this limitation is Apple's desire to keep bad software off the platform and exert control. A surprising number of third parties have embraced this restriction with open arms.
The driving force behind this seems to be a belief that such a restriction is all that stands between the iPhone and a rampaging horde of evil software just waiting to steal your personal information and turn your telephone into a spam zombie. All you have to do is Google for iphone sdk malware to see how prevalent this attitude is.
I don't think the fear is justified, and I also don't think the restrictions will help nearly as much as people think. But first, it's important to distinguish between different kinds of malware, because there is one kind that code signing may stop and one kind that it will not.
The original Trojan Horse was a big wooden statue presented as a gift. The Trojans brought it into their city to celebrate, but it was filled with soldiers waiting for the opportunity to kill everyone. Modern Trojan Horses work pretty much the same way. They present themselves as a shiny app, such as an animated postcard or a game, but behind the scenes they do something naughty.
This is basically the standard case for code signing on the iPhone. Apple, the theory goes, will test all apps before they are approved for the App Store. Any app that behaves badly will be caught and refused. Since you can't get software on the device except through the App Store, you can't get any bad apps. Problem solved.
I'm not sure if things will actually happen this way. Unless the store has an extremely limited selection, the number of apps in the store is going to outstrip Apple's testing resources. A lot of developers have theorized that Apple will do some basic testing but will otherwise rely on their ability to revoke applications after the fact, rather than catching problems up front. Even with extensive testing it would still be easy to hide the evil bits. It's not terribly hard to wrap the evil code in a timer that prevents it from running for a month or two until you're sure that Apple's testing is done. Unlike the Greeks in the Trojan Horse, malicious code won't starve and it can wait as long as it needs to in order to escape detection.
Worms, Viruses, and other Exploits
But the scary scenario isn't Trojan Horses. Remote exploits are scary. In this scenario, you visit a malicious web page and suddenly that page has taken over your phone. Or you receive a specially-formed instant message which breaks into your chat application. Or an attacker simply finds your phone on the internet, sends it a specially crafted packet, and then has the run of the place.
My understanding of code signing as it is currently implemented in OS X is that it will not do anything to prevent these sorts of attacks. This is because, fundamentally, it's difficult to tell the difference between an application which is behaving as it's intended and an application which has been compromised. In both cases, the application receives some data and then performs an action based on it. The only difference is that in the compromise scenario the application is no longer behaving as intended, but how do you (and by "you" I mean a computer operating system) know the author's intent?
In an exploit like this, the attacker takes advantage of a vulnerability in an application which causes it to overwrite some memory, free the same block of memory twice, or something else naughty. It does this in such a way as to cause the application to start doing its bidding, at which point it then gives the app some code and has it transfer control to the newly loaded code. This all happens in memory, long after any signature verification has taken place, so the fact that the newly loaded exploit code is unsigned doesn't matter at all.
This scenario is not merely theoretical. Although I know of no instance in which it was used for evil, this is used on the site jailbreakme.com to jailbreak an iPhone, ironically so that third-party applications can be loaded on it, bypassing the code signature checking.
Jailbreakme.com works by sending the iPhone a specially crafted TIFF image. This image exploits the image decoding software, allowing the site to execute arbitrary code on the user's device. In this case it's entirely benign; the TIFF is used to allow third-party software and patch the exploit it used to gain access in the first place. But it could just as easily start snooping for credit card numbers or offloading the contents of your address book.
The exploit used by that site is now fixed, so it only works on older firmware revisions. But exploits of one kind or another are virtually guaranteed to exist in any firmware revision. It's said that the only truly secure computer is one which is disconnected from the network, turned off, encased in solid concrete, and sunk to the bottom of the ocean. And even then, you never know when the CIA might go dig it up.
This is the scary kind of malware. It's scary because it strikes when you should be safe. Surfing the web or receiving messages should never result in getting your phone hijacked by some guy in Nigeria, whereas when you install a weird untrusted application you should at least have some idea that you may be getting more than you bargained for. Code signing does nothing to stop this kind of attack and only limits it slightly, in that it's stuck running within the host app rather than writing out a daemon that can keep going behind the scenes.
Despite all the doom and gloom above, I don't think the platform is in any particular danger. It's no more vulnerable than any other computer operating system, and much better than some. The only platform currently in existence which really plays host to a great deal of malware is Windows, and that's mainly because it's really, terribly bad at this sort of thing. But while the iPhone code signing requirements may well raise the average quality of the available applications, it's at the cost of considerable freedom. Apple needs to at least make this optional, even if it's on by default. Switching it off isn't going to suddenly cause bad things to happen, much less turn the platform into a "haven for malware" as many seem to fear.
I'll take care of protecting myself from evil, just let me decide what I want to put on my hardware.
Comments RSS feed for this page
Add your thoughts, post a comment:
Spam and off-topic posts will be deleted without notice. Culprits may be publicly humiliated at my sole discretion.