JoeSolutions

For those of you who are interested in how evasi0n technically works, check this out:

iOS 6.1 evasi0n jailbreak

The latest jailbreak is out, and it’s time to dissect it and document all the exploits and techniques it contains.  These days, jailbreaks are so well tested that it’s easy for people to forget all the complexity that goes into them.  There are numerous exploit mitigations in iOS userland, such as sandboxing, ASLR, and code signature requirements that make jailbreaking incredibly difficult.

One important point to make is that unlike the previous jailbreakme.com exploits, which could be used against an unwitting victim, jailbreaks that require USB tethering have a lower security impact, and are usually only useful to the phone’s owner.  Attackers are less interested because iPhones with a passcode set will refuse to communicate over USB if they are locked, unless they have previously paired with the connecting computer.  So your phone is stolen and it’s locked, attackers won’t be able to jailbreak it.  Therefore, only malicious code already running on your computer can leverage USB jailbreaks nefariously.

Evasi0n userland component

This blog post will focus on the evasi0n userland component.  Evasi0n’s userland component is very unique, because it is entirely filesystem-based.  It doesn’t require memory corruption to escalate privileges from mobile to root.  Perhaps it was named evasi0n because it evades all the userland exploit defenses instead of attacking them head-on.

Evasi0n works in 3 stages that are described below.  All of the stages use functionality on the phone exposed by MobileBackup, the daemon used to backup user data from the device, and restore backups back to the device.  Since backups are created by the user’s device, and must be interchangeable between devices, they cannot be easily cryptographically signed, so they are essentially untrusted data.

MobileBackup uses both a domain, such as MediaDomain, and a relative path to identify every file. A static absolute path corresponding to the domain, joined with the file-specific relative path, determines the absolute path of every file.  Evasi0n creates all its files in MediaDomain, so all of the files are within /var/mobile/Media.

Stage 1:

During stage 1, evasi0n creates a fresh backup to restore to the device, containing only the following files.  All files are within the MediaDomain.

directory: Media/
directory: Media/Recordings/
symlink: Media/Recordings/.haxx -> /var/mobile
directory: Media/Recordings/.haxx/DemoApp.app/
file: Media/Recordings/.haxx/DemoApp.app/Info.plist
file: Media/Recordings/.haxx/DemoApp.app/DemoApp
file: Media/Recordings/.haxx/DemoApp.app/Icon.png
file: Media/Recordings/.haxx/DemoApp.app/Icon@2x.png
file: Media/Recordings/.haxx/DemoApp.app/Icon-72.png
file: Media/Recordings/.haxx/DemoApp.app/Icon-72@2x.png
file: Media/Recordings/.haxx/Library/Caches/com.apple.mobile.installation.plist

The symlink in .haxx to /var/mobile is created to escape the MobileBackup domain’s normal path restriction.  That is, normally files in the MediaDomain must reside within /var/mobile/Media; however, with the symlink created any file that exists in .haxx is actually restored in /var/mobile.  This technique has been used in past jailbreaks as well.

Next, DemoApp.app, an iOS app, is created in /var/mobile, complete with icons and other supporting collateral.  The plist com.apple.mobile.installation.plist is updated so that Springboard knows where the app lives, and can display it on the home screen.

However, unlike a normal iOS app, this app contains a very peculiar main binary consisting of just the following:

#!/bin/launchctl submit -l remount -o /var/mobile/Media/mount.stdout -e /var/mobile/Media/mount.stderr — /sbin/mount -v -t hfs -o rw /dev/disk0s1s1

For those unfamiliar with UNIX shell scripts, the kernel looks at the first line of text files to determine the interpreter for the script.  The above file contents tell the kernel to execute launchctl with those specific arguments.

Additionally, com.apple.mobile.installation.plist contains a peculiar section for DemoApp.app, defining an environment variable to set when running it:

<key>EnvironmentVariables</key>
<dict>
<key>LAUNCHD_SOCKET</key>
<string>/private/var/tmp/launchd/sock</string>
</dict>

At this point, the device is rebooted so that the app is picked up by Springboard, and displayed to the user.

Stage 2.1:

Now that the previous files have been put into place, Stage 2 begins by creating a new empty backup, and restoring more files to the device.

directory: Media/
directory: Media/Recordings/
symlink: Media/Recordings/.haxx -> /var/db
symlink: Media/Recordings/.haxx/timezone -> /var/tmp/launchd

Essentially, this just creates a symlink called /var/db/timezone that points to /var/tmp/launchd.  The normal permissions on /var/tmp/launchd are:

drwx—— 2 root   wheel  102 Feb  4 12:17 launchd

These permissions normally prevent applications running as user mobile from descending into this directory.  Next, evasi0n tells the user it is stroking lockdownd.  What that actually means is evasi0n is sending a malformed PairRequest command to lockdownd.  Lockdownd is the main daemon that operates on commands received over USB, and is used to start/stop other services, such as MobileBackup and AFC.  Since lockdownd runs as root and the user can communicate to it, abusing it to perform unintended tasks has become common in recent jailbreaks.

Now we come to the first vulnerability exploited.  Sending lockdownd a malformed PairRequest command, causes lockdownd to chmod 777 /var/db/timezone so that it is accessible to mobile (and all users).  It isn’t clear whether this is a vulnerability in lockdownd or in an underlying library or framework.

Stage 2.2:

Stage 2.2 drills down further into /var/tmp/launchd.  It modifies the permissions in the system so that the launchd socket is also accessible by the mobile user.  Stage 2.2 changes the timezone symlink as follows:

Symlink:  Media/Recordings/.haxx/timezone -> /var/tmp/launchd

To

Symlink:  Media/Recordings/.haxx/timezone -> /var/tmp/launchd/sock

Then evasi0n sends another malformed PairRequest packet to lockdownd, causing /var/tmp/launchd/sock to become accessible to the mobile user.

Stage 2.3:

Stage 2.3 begins by uploading a Cydia and packagelist tarfile to the phone.  This isn’t used immediately, but is uploaded for use after the jailbreak is complete.

Next, the user is instructed to run the Jailbreak app (actually DemoApp.app) on their phone. Recall what that app did:

#!/bin/launchctl submit -l remount -o /var/mobile/Media/mount.stdout -e /var/mobile/Media/mount.stderr — /sbin/mount -v -t hfs -o rw /dev/disk0s1s1

With the environment variable

LAUNCHD_SOCKET = /private/var/tmp/launchd/sock

If you read man launchctl, you will see that the submit command is described as follows:

submit -l label [-p executable] [-o path] [-e path] — command [args]
A simple way of submitting a program to run without a configuration file. This mechanism also tells launchd to keep the program alive in the event of failure.
-l label
What unique label to assign this job to launchd.
-p program
What program to really execute, regardless of what follows the — in the submit sub-command.
-o path  Where to send the stdout of the program.
-e path  Where to send the stderr of the program.

If you look at the manpage for launchd, you will see:

ENVIRONMENTAL VARIABLES

LAUNCHD_SOCKET

This variable is exported when invoking a command via the launchd command line. It informs launchctl how to find the correct launchd socket for communications.

Unlike most other things on iOS, launchd’s IPC mechanism operates through unix domain sockets.  There are also multiple launchd processes – one running as each user.  On iOS, there is one running as root, and one running as mobile.  So the user, as mobile, is executing launchctl via DemoApp.app.  However, launchctl is not talking to the mobile user’s launchd.  Instead, it is talking to the root user’s launchd, via the launchd socket that was exposed via UNIX permissions using the /var/db/timezone vulnerability.

Since the root user’s launchd runs as root, this job will be run as root.  The job will remap the system partition as read-write, allowing the exploit to then make persistent changes on the system partition that will execute as root in the early boot environment.

Stage 3:

Next, the final stage of the jailbreak begins, again using MobileBackup, but this time with full access to the system partition.

directory: Media/
directory: Media/Recordings/
symlink: Media/Recordings/.haxx -> /
symlink: Media/Recordings/.haxx/private/etc/launchd.conf -> /private/var/evasi0n/launchd.conf
directory: Media/Recordings/.haxx/var/evasi0n
file: Media/Recordings/.haxx/var/evasi0n/evasi0n
file: Media/Recordings/.haxx/var/evasi0n/amfi.dylib
file: Media/Recordings/.haxx/var/evasi0n/udid
file: Media/Recordings/.haxx/var/evasi0n/launchd.conf

Things are getting a bit confusing due to extensive use of pushing files through symlinks, but essentially this creates a directory at /var/evasi0n containing an executable, a library, and a new launchd.conf.  Launchd.conf is described by Apple (see man launchd.conf) as:

DESCRIPTION

launchd.conf contains a list of subcommands (load, unload, etc.) to run via launchctl(1) when launchd(8) starts.

The replacement launchd.conf, which will run at each boot, contains:

bsexec .. /sbin/mount -u -o rw,suid,dev /

setenv DYLD_INSERT_LIBRARIES /private/var/evasi0n/amfi.dylib

load /System/Library/LaunchDaemons/com.apple.MobileFileIntegrity.plist

bsexec .. /private/var/evasi0n/evasi0n

unsetenv DYLD_INSERT_LIBRARIES

bsexec .. /bin/rm -f /private/var/evasi0n/sock

bsexec .. /bin/ln -f /var/tmp/launchd/sock /private/var/evasi0n/sock

Here’s what that does, line by line:

bsexec .. /sbin/mount -u -o rw,suid,dev /

Mount system partition read-write again

setenv DYLD_INSERT_LIBRARIES /private/var/evasi0n/amfi.dylib

Insert amfi.dylib into any executable that launches after this point

load /System/Library/LaunchDaemons/com.apple.MobileFileIntegrity.plist

Load the MobileFileIntegrity daemon

bsexec .. /private/var/evasi0n/evasi0n

Execute the malicious code, previously dropped in /var/evasi0n/evasi0n

unsetenv DYLD_INSERT_LIBRARIES

Unset DYLD_INSERT_LIBRARIES, so that amfi.dylib will no longer be inserted into every executable after this point

bsexec .. /bin/rm -f /private/var/evasi0n/sock

Delete any pre-existing socket file at /private/var/evasi0n/sock

bsexec .. /bin/ln -f /var/tmp/launchd/sock /private/var/evasi0n/sock

Create a symlink from /var/tmp/launchd/sock to /private/var/evasi0n/sock, allowing other code direct access to the root launchd socket

Next, the exploit reboots the device, causing this configuration file to get run, line by line, on next boot.  The interesting thing about amfi.dylib and evasi0n is that neither are code-signed.  If you look at amfi.dylib with otool, you will see that it in fact has no TEXT/text section at all.  No TEXT/text section means that there is nothing to sign, and therefore, it won’t trip up the code-signing machinery.  What it does have, is lazy binding information.
$ dyldinfo -export amfi.dylib
export information (from trie):
[re-export] _kMISValidationOptionValidateSignatureOnly (_kCFUserNotificationTokenKey from CoreFoundation)
[re-export] _kMISValidationOptionExpectedHash (_kCFUserNotificationTimeoutKey from CoreFoundation)
[re-export] _MISValidateSignature (_CFEqual from CoreFoundation)

This technique is described, at least, at http://networkpx.blogspot.com/2009/09/compiling-iphoneos-31-apps-with-xcode.html:

“If we can force MISValidateSignature() to always return 0, any binaries will pass the test. This function is part of libmis.dylib, which is now part of the shared cache, so you can’t binary patch this file. Replacing the implementation of a function is a perfect job with MobileSubstrate, unfortunately, no matter how I tried MS can’t be injected. Therefore I use a trick: create a “proxy dynamic library” that changes only the MISValidateSignature function, and let the rest pass through.”

By clever usage of a codeless dynamic library, existing valid methods (such as CFEqual()) can be re-exported as different methods with the same method signature, such that MISValidateSignature will always return 0, allowing any unsigned binary to run.

Conclusion

Evasi0n is interesting because it escalates privileges and has full access to the system partition all without any memory corruption.  It does this by exploiting the /var/db/timezone vulnerability to gain access to the root user’s launchd socket.  It then abuses launchd to load MobileFileIntegrity with an inserted codeless library, which is overriding MISValidateSignature to always return 0.