mikeash.com pyblog/deconstructing-the-iphone-sdk-malware.html comments

mikeash - 2008-03-21 08:34:59

Fri, 21 Mar 2008 08:34:59 GMT

Forcing all code to be signed in memory seems like it would prevent a large useful class of code from running, namely anything using just-in-time compiling, dynamically constructed trampolines, and other such things. But then again that doesn't mean they wouldn't do it....

If such a thing is enabled, then the options are reduced to convincing the code to do things for you without handing it any new machine code. Any application which contains an interpreter may be vulnerable to this sort of thing, and attacks like SQL injection would still be possible, but it would certainly limit the options for mayhem.

mikeash - 2008-03-21 08:00:04

Fri, 21 Mar 2008 08:00:04 GMT

I have no doubt these problems can be addressed. The point of my post wasn't that the platform is doomed regardless. Quite the opposite in fact; it's in good shape no matter what. The code signing requirements are destructive and onerous, but everyone is saying that they're needed to make the platform safe. My intent is to demonstrate that this is incorrect, that it's already reasonably safe, and that it won't get any safer with these requirements anyway.

Fine grained privileges is an excellent idea and I look forward to seeing it not just on the iPhone but on my regular computers as well. There's no reason a web browser should be able to destroy the contents of my home directory or read my private documents, and if access controls are in place so that it can't, the sort of exploit that jailbreakme.com uses will become much less destructive.

das - 2008-03-21 07:58:32

Fri, 21 Mar 2008 07:58:32 GMT

The Leopard codesigning infrastructure supports signature verification of in-memory code and has a 'kill' option that causes signed code to die as soon as its signature becomes invalid (dynamic validity c.f. 'man codesign' & the WWDC07 codesigning session).

No idea if the iPhone has this support (and if it does whether it will make use of it in 2.0), but if yes, signature verification is not restricted to initial code loading time as you are suggesting.

If all application code and all the OS libray code is signed and has the kill option set, a large class of attacks become impossible as the OS can enforce that all code executed in userspace needs a valid signature at runtime, i.e. if a sucessful code injection into an app were to take place e.g. via an image format decoding bug, the app would die upon jumping into the injected code.

Of course this would not prevent running harmful code that _is_ signed, like the Trojans you mention...

Chad Sellers - 2008-03-21 07:41:41

Fri, 21 Mar 2008 07:41:41 GMT

While you're correct that code signing won't solve the security problems you outline, that doesn't mean that they can't be addressed. One common way of addressing them is to utilize OS access control policies, like those used in SELinux. As of Leopard, OS X has such a mechanism which they refer to as sandboxes. I blogged about these when Leopard came out at http://www.usefulsecurity.com. Leopard only confines a few applications, but the mechanism is there to confine more. I don't have the iPhone SDK (and if I did I'd be under NDA so I couldn't talk about it anyway), but they could easily use the same mechanism on the iPhone to confine applications. Protecting against these sort of attacks is definitely possible, though it remains to be seen if they'll utilize it. Clearly they didn't in the 1.x firmware versions, or jailbreakme wouldn't work. Perhaps that will change with the 2.x firmware.

mikeash - 2008-03-21 05:34:00

Fri, 21 Mar 2008 05:34:00 GMT

charles: That's a fine question. Despite only having two headings to my post, there are really three attack vectors here.

Trojans: These are pretty common on the Windows side. They tend to be passive, but get spread because they give the user enough gratification that they want to show their friends. It gets spread around by e-mail, generally, infecting people as it goes. A nastier variant on this will take it upon itself to e-mail your friends for you once you run it, speeding the process along. It still requires manual intervention to run it after it's received. Requiring code to be signed by Apple and obtained through the App Store will pretty much stop this. If it's possible to sneak a trojan through Apple's checks then this will show up as people e-telling each other to download these apps because they have cute dancing gnomes or whatever the hook is.

Passive exploits: This is the jailbreakme.com approach. You leave some maliciously crafted data around where a user might try to load it in a program which can be exploited. This can't spread at all except for gray areas like exploiting communications apps which let you talk to your friends, like mail, chat, twitter, and other such services. Code signing does nothing against this because, as noted in the post, you're just taking over a trusted app rather than trying to load a new, untrusted app.

Active exploits: This is where you find a vulnerability on a machine which can be exploited directly over the internet. Many famous Windows worms operated this way, and they can be tremendously destructive. The iPhone should be quite secure if it's built properly. A quick scan of my iPod Touch using nmap shows no open ports, as it should be. Hopefully no such exploits will be found. Again, code signing doesn't help because you're taking over a trusted app.

Assuming that there are no active exploits discovered, the scariest scenario is probably where an exploit is found in Mail, or in a popular chat program. This is a very real possibility and code signing, as far as I know, won't help against it.

Casey: Good to see you around here. The question of holding Apple liable is an interesting one, and I can certainly see it happening. For the record I have no objection to Apple vetting and restricting the behavior of apps available through the official App Store. All I want is a way to bypass the app store, both for my own personal projects and so I can use software that Apple doesn't approve of. Since Apple has yet to be sued (to my knowledge!) for any of the horrible software which exists on the Mac, I can't imagine anyone would try to hold them liable for third-party software obtained and loaded directly without passing through Apple.

Casey - 2008-03-21 05:19:45

Fri, 21 Mar 2008 05:19:45 GMT

This is interesting. Although I'm sure upon installation of an app from the App Store the user will be warned that Apple is not liable for any harm caused by the application, there will nevertheless be attempts to hold them responsible as Apple is promoting the App Store as a repository that filters out just this sort of thing. Whether or not they'll be open to any legal action (probably not), if / when a problem arises there will no doubt be many that look to Apple, instead of the original developer, for restitution or compensation.

charles - 2008-03-21 03:16:03

Fri, 21 Mar 2008 03:16:03 GMT

Could you comment on how and if the restrictions put on the application access to low-level stuff will help in fighting not the infection itself but at least the spreading of exploits? While one can get malware from visitng a web site, this only affects a limited number of users; the big risk is in spreading from machine to machine, and have something endemic.