分类： LINUX
2010-12-02 10:40:49
This is a bit of a follow up to our , but we thought it would 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 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: .
Android does not have a separate udev executable and process link on standard Linux deployments. However, large portions of the udev code have been moved into the init daemon (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, is the init process 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 would 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 to). It will then send a 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 of /system/bin/sh as /system/bin/rootshell with the permissions of 04711 (executable with the user ID bit set so it always runs as root).
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 setting. This is the maximum number of simultaneous processes which the system will allow. A quick “ulimit -a” once connected over adb should 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 running adb daemon 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. will later check if it should 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.
