Intrepid iPhone developers bypass security for functionality

The Apple iPhone is vulnerable to a new bug related to the signing of iPhone applications.  Applications that are created with the official iPhone SDK need to be cryptographically signed by the author and Apple before they’re allowed into the App store or installed on an iPhone.  The digital signing is a security measure that serves two purposes; helping to identify the developer in case of any problems and making sure that an approved application hasn’t been modified.

An iPhone developer discovered the bug while looking for a way to duplicate a feature of Apple created iPhone applications: dynamic default.png files.  The default.png file is displayed when an iPhone application is launched and can be used as a static splashscreen.  When you quit an Apple created application, it takes a snapshot of the screen when you quit and saves it as default.png within itself.  The next time you start the app it loads the new default.png, and everything looks like it was when it was last run. The application hasn’t fully loaded yet, but the saved default.png trick makes it look that way.

Unlike Apple’s apps, those created by other developers can’t modify their default.png files. Since the default.png is stored within the application as a part of itself, it gets digitally signed.  Modifying the image file and thus the app, makes the digital signature invalid.  An alternative would be to use a default.png in the application’s data directory, but only the file within the application is supported on the iPhone.

The method to replicate Apple’s default.png trick involves a defect in the codesign utility in the iPhone SDK.  codesign is the utility used by developers when they digitally sign their applications.  Normally codesign will take every file within an iPhone application into account when it creates the digital signature.  the problem with codesign is that it doesn’t handle symbolic links (symlinks) properly.

Symlinks are like shortcuts to files; if you want to refer to one file in two locations or with two different names you can create a symlink in the new location.  The symlink isn’t a new file copy, just a pointer to the original file.  codesign doesn’t follow the pointer to the original file, so it doesn’t consider that file during signing.  The new approach is to create a symlink named default.png that points to a location or file outside of the application that can be easily modified.

This is a neat trick, but harmless.  If it were only the codesign utility that has this symlink problem, then the technique would not work for an installed application.  The real trouble arises when symlinks are used to obscure other program files or components during signing.  The digital signature process was intended to ensure that no unapproved or unsafe modifications could occur.  An attacker could arrange for malicious components to be installed using a self-update feature.  Since the digital signature ignores symlinks, the malicious application could contain pointers to the yet to be downloaded parts.  Since the bad portions of the program don’t exist during the approval process, malicious applications can sneak through.  This effectively bypasses the iPhone OS’s protection against the running of malicious code.

Fortunately, since the application is signed, tracking down the author of such malware should be considerably easier.  Given that the vulnerability lies within a utility in the iPhone SDK and within the iPhone OS’s verification system, it should be fixed shortly in a future update.