Two Methods for Android root: udev vulnerability and setuid Vulnerability

Reprinted from: http://intrepidusgroup.com/insight/2010/09/android-root-source-code-looking-at-the-c-skills/

Root andoid currently mainly relies on two vulnerabilities: udev of the init process and setuid of the adbd process. The following describes in detail. The rageagainstthecage program mentioned in previous articles uses the setuid vulnerability.

The source code of these two vulnerabilities is here:/files/super119/rageagainstthecage.zip

 

This is a bit of a follow up to our previous post, but we thought it wocould be interesting to dissect the source code of two of the recent Android root attacks: the udev exploit and the ADB setuid exhaustion attack. the C-Skillz site has posted the code for both exploits in the downloads available from their site. as they state, these attacks work basically against all Android phones released to date (and probably future ones if they run Android 2.1 or 2.2 ).

The udev exploit gained attention as one of the first attacks used against the Droid X, but was posted on the C-Skillz site about a week before it made a great deal of noise on other blogs and forums. the download also included a ReadMe file which points out this attack mainly follows the exploit reported against udev and patched in 2009. here's a link to the CVE it points out: CVE-2009-1185.

Android does not have a separateUdevExecutable and process link on standard Linux deployments. However, large portions of the udev code have been moved intoInitDaemon (Init, Like on a standard Linux system, is typically the first userland process and runs as root ). in a simplistic and brief Nutshell, udev offers dynamic management of devices; notably, it allows Standard Users to "hotplug" devices that may require root level access, such as a USB device. the kernel will pass a message to the userland udev demon, which will in turn act on the message. the issue is that versions of udev before 1.4.1 did not verify if these messages actually came from the kernel. thus, a rogue application can submit a message to udev and have an action executed (which in the case of Android, isInitProcess running as root ). while the kernel will need to be updated to send credentials with its messages to udev, The userland udev/INIT process is really where this vulnerability exists. I had originally referred to this as a kernel exploit, but that wowould technically be incorrect.

So here's a quick overview of the exploid. C code: when the application runs, it copies itself to the sqlite_stmt_journals directory (remember, we're not root yet, so we need a directory the "shell" user can write ). it will then send a netlink_kobject_uevent message to run the copy of itself when the next hotplug event is triggered. the copied version of the executable then check if it is being run as root (this is our userland udev/INIT process) and if so, remounts the system partition (which is normally mounted as a read-only partition) and dumps a copy/System/bin/shAs/system/bin/rootshell with the permissions of 04711 (executable with the user ID bit set so it always runsRoot).

Now lets look at the ADB setuid exhaustion attack. compiled, this typically has the name "rageagainstthecage" and the Code refers to it has "CVE-2010-EASY" in one comment, but whatever you call it, it's a pretty smooth way of getting adbd (Android's debugging bridge Daemon) to run as root. first the code will check that there is an nproc setting. this is the maximum number of simultaneous processes which the system will allow. A quick "ulimit-A" once connected over ADB shocould show you this setting for your device (this is set to 3301 processes on a droid incredible ). the code will then try to find the process ID of the currently runningADBDaemon on the device. after that, the attack starts a loop to generated processes until it can no longer fork any more processes. once the limit is hit, one process is killed off and the ADB daemon process is restarted. as the code comment points out, this is a bit of a race at this point to make sure the ADB can restart, but the number of processes stays maxed out. when the ADB daemon starts up on an Android device, it is running as root. the code will later check if it shoshould stay as root, or run in "secure" mode which drops its privileges to the "shell" account. this attack attemps to max out the process so that when the ADB daemon attempts to call "setuid" in its code, the call will fail. the current ADB Code does not check if the setuid call was successful or not, so will happily keep running as root even if this fails.

Post a comment or leave a trackback: trackback URL.