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.
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.
By Peter Morgan, Ryan Smith, Braden Thomas, and Josh Thomas
扫一扫
1415
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
