Gaining initial root access on a booted system consists of getting a root shell through an unpatched security fl aw in the Android operating system. A rooting method like this is also widely known as a soft root because the attack is almost entirely software based. Usually, a soft root is accomplished through a vulnerability in the Android kernel, a process running as root, a vulnerable program with the set-uid bit set, a symbolic link attack against a fi le permission bug, or other issues. There are a vast number of possibilities due to the sheer number of areas in which issues could be introduced and types of mistakes programmers could make. Although root set-uid or set-gid binaries are not common in stock Android, carriers or device manufacturers sometimes introduce them as part of their custom modifi cations. A typical security fl aw in any of these set-uid binaries can lead to privilege escalation and subsequently yield root access. Another typical scenario is exploiting a security vulnerability in a process running with root privileges. Such an exploit enables you to execute arbitrary code as root. The end of this chapter includes some examples of this. As you will see in Chapter 12, these exploits are becoming more diffi cult to develop as Android matures. New mitigation techniques and security hardening features are regularly introduced with new Android releases.
Abusing adbd to Get Root
It is important to understand that the adbd daemon will start running as root and drop its privileges to the shell user (AID_SHELL) unless the system property ro.secure is set to 0. This property is read-only and is usually set to ro.secure=1 by the boot image initrd. The adbd daemon will also start as root without dropping privileges to shell if the property ro.kernel.qemu is set to 1 (to start adbd running as root on the Android emulator), but this is also a read-only property that will not normally be set on a real device. Android versions before 4.2 will read the /data/local.prop fi le on boot and apply any properties set in this fi le. As of Android 4.2 this fi le will only be read on non-user builds, if ro.debuggable is set to 1. The /data/local.prop fi le and the ro.secure and ro.kernel.qemu properties are of key importance for gaining root access. Keep those in mind, as you will see some exploits using them in the “History of Known Attacks” section later in this chapter.
NAND Locks, Temporary Root, and Permanent Root
Some HTC devices have a security fl ag (@secuflag) in the radio Non-Volatile Random Access Memory (NVRAM) which is checked by the device boot loader (HBOOT). When this fl ag is set to “true” the boot loader displays a “security on” message (S-ON) and a NAND lock is enforced. The NAND lock prevents writing to the system, boot, and recovery partitions. With S-ON, a reboot loses root, and writes on these partitions won’t stick. This makes custom system ROMs, custom kernels, and custom recovery modifi cations impossible. It is still possible to gain root access through an exploit for a suffi ciently severe vulnerability. However, the NAND lock causes any changes to be lost on reboot. This is known as a temporary root in the Android modding community. To achieve a permanent root on HTC devices with a NAND lock, one of two things must be done. First, you can disable the security fl ag in the baseband. Second, you can fl ash the device with a patched or engineering HBOOT that does not enforce NAND locking. In both cases, the boot loader displays a security off message (S-OFF). Figure 3-3 shows a locked and unlocked HTC HBOOT.
Before HTC provided the offi cial boot loader unlock procedure in August 2011, a patched HBOOT was the only solution available. This could be accomplished on some devices by unoffi cial boot loader unlock tools such as AlphaRev (available at http://alpharev.nl/) and Unrevoked (available at http://unrevoked.com/), which later merged into the Revolutionary.io tool (available at http://revolutionary.io/). Those tools usually combine multiple public or private exploits to be able to fl ash the patched boot loader and bypass NAND locks. In most cases, refl ashing a stock HBOOT re-enables the device security fl ag (S-ON). The Unlimited.io exploits available at http://unlimited.io/, such as JuopunutBear, LazyPanda, and DirtyRacun, allow gaining full radio S-OFF on some devices by combining several exploits present in HTC’s Android ROMs and the device’s baseband. In December 2010, Scott Walker published the gfree exploit available at https://github.com/tmzt/g2root-kmod/tree/master/scotty2/gfree under the GPL3 license. This exploit disabled the embedded MultiMediaCard (eMMC) protection of the T-Mobile G2. The eMMC memory, which holds the baseband partition, is booted in read-only mode when the bootloader initializes the hardware. The exploit then power-cycles the eMMC chip by using a Linux kernel module and sets the @secuflag to false. Finally, it installs a MultiMediaCard (MMC) block request fi lter in the kernel to remove the write protection on the hidden radio settings partition. When HTC started its offi cial unlock portal, it provided HBOOT images for some devices which allow the user to unlock the boot loader—and remove NAND locks—in two steps:
1. First the user should run the command fastboot oem get_identifier_ token. The boot loader displays a blob that the user should submit to HTC’s unlock portal.
2. After submitting the identifi er token, the user receives an Unlock_code .bin fi le unique for his phone. This fi le is signed with HTC’s private key and should be fl ashed to the device using the command fastboot flash unlocktoken Unlock_code.bin.
If the Unlock_code.bin fi le is valid, the phone allows using the standard fastboot flash commands to fl ash unsigned partition images. Further, it enables booting such unsigned partition images without restrictions. Figure 3-4 depicts the general workfl ow for unlocking devices. HTC and Motorola are two OEMs that utilize this type of process. Other devices, such as some Toshiba tablets, also have NAND locks. For those devices, the locks are enforced by the sealime Loadable Kernel Module, which resides in the boot image initrd. This module is based on SEAndroid and prevents remounting the system partition for writing.
Persisting a Soft Root
When you have a root shell (soft root), achieving permanent root access is straightforward. On phones without NAND locks, you only need write access to the system partition. If the phone has a NAND lock, it should be removed fi rst (refer to the “NAND Locks, Temporary Root, and Permanent Root” section earlier in this chapter). With NAND locks out of the picture, you can simply remount the system partition in read/write mode, place an su binary with set-uid root permissions, and remount it in read-only mode again; optionally, you can install an su wrapper such as SuperUser or SuperSU.
A typical way of automating the process just described is by running the following commands from a host computer connected to an Android device with USB debugging enabled:
adb shell mount -o remount,rw /system
adb adb push su /system/xbin/su
adb shell chown 0.0 /system/xbin/su
adb shell chmod 06755 /system/xbin/su
adb shell mount -o remount,ro /system
adb install Superuser.apk
Another way of retaining persistent root access is by writing a custom recovery into the recovery partition using the dd command on the Android device. This is equivalent to fl ashing a custom recovery via fastboot or download mode, as described in the “Rooting with an Unlocked Boot Loader” section earlier in this chapter. First, you need to identify the location of the recovery partition on the device. For example:
[email protected]:/ # ls -l /dev/block/platform/*/by-name/recovery
lrwxrwxrwx root root 2012-11-20 14:53 recovery -> /dev/block/mmcblk0p7
The preceding output shows the recovery partition in this case is located at /dev/block/mmcblk0p7.
The remainder of this section discusses numerous previously known methods for gaining root access to Android devices. By presenting these issues, we hope to provide insight into the possible ways you can gain root access to Android devices. Although a few of these issues affect the larger Linux ecosystem, most are Android specifi c. Many of these issues cannot be exploited without access to the ADB shell. In each case we discuss the root cause of the vulnerability and key details of how the exploit leveraged it.
(NOTE) The astute reader may notice that several of the following issues were unknowingly discovered by multiple, separate parties. Although this is not a common occurrence, it does happen from time to time.
Some of the exploitation details provided in this section are rather technical. If they are overwhelming, or you are already intimately familiar with the inner workings of these exploits, feel free to skip past them. In any case, this section serves to document these exploits in moderate detail. Chapter 8 covers a few of these exploits in more detail.
Kernel: Wunderbar/asroot
This bug was discovered by Tavis Ormandy and Julien Tinnes of the Google Security Team and was assigned CVE-2009-2692:
The Linux kernel 2.6.0 through 2.6.30.4 and 2.4.4 through 2.4.37.4, does not initialize all function pointers for socket operations in proto_ops structures, which allows local users to trigger a NULL pointer dereference and gain privileges by using mmap to map page zero, placing arbitrary code on this page, and then invoking an unavailable operation, as demonstrated by the sendpage operation (sock_sendpage function) on a PF_PPPOX socket.
Brad Spengler (spender) wrote the Wunderbar emporium exploit for x86/ x86_64, which is where this bug got its famous name. However, the exploit for Android (Linux on the ARM architecture) was released by Christopher Lais (Zinx), is named asroot, and is published at http://g1files.webs.com/Zinx/android-root-20090816.tar.gz. This exploit worked on all Android versions that used a vulnerable kernel. The asroot exploit introduces a new “.NULL” section at address 0 with the exact size of a page. This section contains code that sets the current user identifi er (UID) and group identifi er (GID) to root. Next, the exploit calls sendfile to cause a sendpage operation on a PF _BLUETOOTH socket with missing initialization of the proto _ops structure. This causes the code in the “.NULL” section to be executed in kernel mode, yielding a root shell.
Recovery: Volez
A typographical error in the signature verifi er used in Android 2.0 and 2.0.1 recovery images caused the recovery to incorrectly detect the End of Central Directory (EOCD) record inside a signed update zip fi le. This issue resulted in the ability to modify the contents of a signed OTA recovery package. The signature verifi er error was spotted by Mike Baker ([mbm]) and it was abused to root the Motorola Droid when the fi rst offi cial OTA package was released. By creating a specially crafted zip fi le, it was possible to inject an su binary into the signed OTA zip fi le. Later, Christopher Lais (Zinx) wrote Volez, a utility for creating customized update zip fi les out of a valid signed update zip, which is available at http://zenthought.org/content/project/volez.
Udev: Exploid
This vulnerability affected all Android versions up to 2.1. It was originally discovered as a vulnerability in the udev daemon used on x86 Linux systems. It was assigned CVE-2009-1185. Later, Google reintroduced the issue in the init daemon, which handles the udev functionality in Android. The exploit relies on udev code failing to verify the origin of a NETLINK message. This failure allows a user-space process to gain privileges by sending a udev event claiming to originate from the kernel, which was trusted. The original Exploid exploit released by Sebastian Krahmer (“The Android Exploid Crew”) had to be run from a writable and executable directory on the device. First, the exploit created a socket with a domain of PF_NETLINK and a family of NETLINK _KOBJECT _UEVENT (kernel message to user-space event). Second, it created a fi le hotplug in the current directory, containing the path to the exploid binary. Third, it created a symbolic link called data in the current directory, pointing to /proc/sys/kernel/hotplug. Finally, it sent a spoofed message to the NETLINK socket. When init received this message, and failed to validate its origin, it proceeded to copy the contents of the hotplug fi le to the fi le data. It did this with root privileges. When the next hotplug event occurred (such as disconnecting and reconnecting the Wi-Fi interface), the kernel executed the exploid binary with root privileges. At this point, the exploit code detected it was running with root privileges. It proceeded to remount the system partition in read/write mode and created a set-uid root shell as /system/bin/rootshell.
Adbd: RageAgainstTheCage
As discussed in the “Abusing adbd to Get Root” section, the ADB daemon (adbd process) starts running as root and drops privileges to the shell user. In Android versions up to 2.2, the ADB daemon did not check the return value of the setuid call when dropping privileges. Sebastian Krahmer used this missing check in adbd to create the RageAgainstTheCage exploit available at http://stealth.openwall.net/xSports/RageAgainstTheCage.tgz. The exploit has to be run through the ADB shell (under the shell UID). Basically, it forks processes until the fork call fails, meaning that the limit of process for that user has been reached. This is a kernel-enforced hard limit called RLIMIT _ NPROC, which specifi es the maximum number of processes (or threads) that can be created for the real UID of the calling process. At this point, the exploit kills adbd, causing it to restart (as root again). Unfortunately, this time adbd can’t drop privileges to shell because the process limit has been reached for that user. The setuid call fails, adbd doesn’t detect this failure, and therefore continues running with root privileges. Once successful, adbd provides a root shell through adb shell command.
As discussed in the “Abusing adbd to Get Root” section, the ADB daemon (adbd process) starts running as root and drops privileges to the shell user. In Android versions up to 2.2, the ADB daemon did not check the return value of the setuid call when dropping privileges. Sebastian Krahmer used this missing check in adbd to create the RageAgainstTheCage exploit available at http://stealth.openwall.net/xSports/RageAgainstTheCage.tgz. The exploit has to be run through the ADB shell (under the shell UID). Basically, it forks processes until the fork call fails, meaning that the limit of process for that user has been reached. This is a kernel-enforced hard limit called RLIMIT _ NPROC, which specifi es the maximum number of processes (or threads) that can be created for the real UID of the calling process. At this point, the exploit kills adbd, causing it to restart (as root again). Unfortunately, this time adbd can’t drop privileges to shell because the process limit has been reached for that user. The setuid call fails, adbd doesn’t detect this failure, and therefore continues running with root privileges. Once successful, adbd provides a root shell through adb shell command.
As discussed in the “Abusing adbd to Get Root” section, the ADB daemon (adbd process) starts running as root and drops privileges to the shell user. In Android versions up to 2.2, the ADB daemon did not check the return value of the setuid call when dropping privileges. Sebastian Krahmer used this missing check in adbd to create the RageAgainstTheCage exploit available at http://stealth.openwall.net/xSports/RageAgainstTheCage.tgz.
The exploit has to be run through the ADB shell (under the shell UID). Basically, it forks processes until the fork call fails, meaning that the limit of process for that user has been reached. This is a kernel-enforced hard limit called RLIMIT _ NPROC, which specifi es the maximum number of processes (or threads) that can be created for the real UID of the calling process. At this point, the exploit kills adbd, causing it to restart (as root again). Unfortunately, this time adbd can’t drop privileges to shell because the process limit has been reached for that user. The setuid call fails, adbd doesn’t detect this failure, and therefore continues running with root privileges. Once successful, adbd provides a root shell through adb shell command.
Zygote: Zimperlich and Zysploit
Recall from Chapter 2 that all Android applications start by being forked from the Zygote process. As you might guess, the zygote process runs as root. After forking, the new process drops its privileges to the UID of the target application using the setuid call. Very similar to RageAgainstTheCage, the Zygote process in Android versions up to 2.2 failed to check the return value of the call to setuid when dropping privileges. Again, after exhausting the maximum number of processes for the application’s UID, zygote fails to lower its privileges and launches the application as root.
Recall from Chapter 2 that all Android applications start by being forked from the Zygote process. As you might guess, the zygote process runs as root. After forking, the new process drops its privileges to the UID of the target application using the setuid call. Very similar to RageAgainstTheCage, the Zygote process in Android versions up to 2.2 failed to check the return value of the call to setuid when dropping privileges. Again, after exhausting the maximum number of processes for the application’s UID, zygote fails to lower its privileges and launches the application as root.
Ashmem: KillingInTheNameOf and psneuter
The Android Shared Memory (ashmem) subsystem is a shared memory allocator. It is similar to POSIX Shared Memory (SHM), but with different behavior and a simpler fi le-based application programming interface (API). The shared memory can be accessed via mmap or fi le I/O.
Two popular root exploits used a vulnerability in the ashmem implementation of Android versions prior to 2.3. In affected versions, ashmem allowed any user to remap shared memory belonging to the init process. This shared memory contained the system properties address space, which is a critical global data store for the Android operating system. This vulnerability has the Common Vulnerabilities and Exposures (CVE) identifi er CVE-2011-1149.
The KillingInTheNameOf exploit by Sebastian Krahmer remapped the system properties space to be writable and set the ro.secure property to 0. After rebooting or restarting adbd, the change in the ro.secure property enabled root access through the ADB shell. You can download the exploit from http://c-skills.blogspot.com.es/2011/01/adb-trickery-again.html.
The psneuter exploit by Scott Walker (scotty2), used the same vulnerability to restrict permissions to the system properties space. By doing so, adbd could not read the value of the ro.secure property to determine whether or not to drop privileges to the shell user. Unable to determine the value of ro.secure, it assumed that ro.secure value was 0 and didn’t drop privileges. Again, this enabled root access through the ADB shell. You can download psneuter at https://github.com/tmzt/g2root-kmod/tree/scotty2/scotty2/psneuter.
Vold: GingerBreak
This vulnerability has been assigned CVE-2011-1823 and was fi rst demonstrated by Sebastian Krahmer in the GingerBreak exploit, available at http://c-skills.blogspot.com.es/2011/04/yummy-yummy-gingerbreak.html.
The volume manager daemon (vold) on Android 3.0 and 2.x before 2.3.4 trusts messages that are received from a PF_NETLINK socket, which allows executing arbitrary code with root privileges via a negative index that bypasses a maximum-only signed integer check.
Prior to triggering the vulnerability, the exploit collects various information from the system. First, it opens /proc/net/netlink and extracts the process identifi er (PID) of the vold process. It then inspects the system’s C library (libc.so) to fi nd the system and strcmp symbol addresses. Next, it parses the Executable and Linkable Format (ELF) header of the vold executable to locate the Global Offset Table (GOT) section. It then parses the vold.fstab fi le to fi nd the device’s /sdcard mount point. Finally, in order to discover the correct negative index value, it intentionally crashes the service while monitoring logcat output.
After collecting information, the exploit triggers the vulnerability by sending malicious NETLINK messages with the calculated negative index value. This causes vold to change entries in its own GOT to point to the system function. After one of the targeted GOT entries is overwritten, vold ends up executing the GingerBreak binary with root privileges.
When the exploit binary detects that it has been executed with root privileges, it launches the fi nal stage. Here, the exploit fi rst remounts /data to remove the nosuid fl ag. Then it makes /data/local/tmp/sh set-uid root. Finally, it exits the new process (running as root) and executes the newly created set-uid root shell from the original exploit process. A more detailed case study of this vulnerability is provided in the “GingerBreak” section of Chapter 8.
PowerVR: levitator
In October 2011, Jon Larimer and Jon Oberheide released the levitator exploit at http://jon.oberheide.org/files/levitator.c. This exploit uses two distinct vulnerabilities that affect Android devices with the PowerVR SGX chipset. The PowerVR driver in Android versions up to 2.3.5 specifi cally contained the following issues.
CVE-2011-1350: The PowerVR driver fails to validate the length parameter provided when returning a response data to user mode from an ioctl system call, causing it to leak the contents of up to 1MB of kernel memory. CVE-2011-1352: A kernel memory corruption vulnerability that leads any user with access to /dev/pvrsrvkm to have write access to the previous leaked memory.
The levitator exploit takes advantage of these two vulnerabilities to surgically corrupt kernel memory. After achieving privilege escalation, it spawns a shell. A more detailed case study of this vulnerability is provided in Chapter 10.
Libsysutils: zergRush
The Revolutionary team released the popular zergRush exploit in October 2011; sources are available at https://github.com/revolutionary/zergRush. The vulnerability exploited was assigned CVE-2011-3874, as follows:
Stack-based buffer overflow in libsysutils in Android 2.2.x through 2.2.2 and 2.3.x through 2.3.6 allows user-assisted remote attackers to execute arbitrary code via an application that calls the FrameworkListener:: dispatchCommand method with the wrong number of arguments, as demonstrated by zergRush to trigger a use-after-free error.
The exploit uses the Volume Manager daemon to trigger the vulnerability, as it is linked against the libsysutils.so library and runs as root. Because the stack is non-executable, the exploit constructs a Return Oriented Programming (ROP) chain using gadgets from libc.so library. It then sends vold a specially crafted FrameworkCommand object, making the RunCommand point to the exploit’s ROP payload. This executes the payload with root privileges, which drops a root shell and changes the ro.kernel.qemu property to 1. As mentioned previously, this causes ADB to restart with root privileges.
A more detailed case study of this vulnerability is provided in Chapter 8.
Kernel: mempodroid
The vulnerability was discovered by Jüri Aedla, and was assigned CVE identifi er CVE-2012-0056:
The mem_write function in Linux kernel 2.6.39 and other versions, when ASLR is disabled, does not properly check permissions when writing to / proc/<p(i)d>/mem, which allows local users to gain privileges by modifying process memory, as demonstrated by Mempodipper.
The /proc/<p(i)d>/mem proc fi le system entry is an interface that can be used to access the pages of a process’s memory through POSIX fi le operations such as open, read, and lseek. In kernel version 2.6.39, the protections to access other processes memory were mistakenly removed.
Jay Freeman (saurik) wrote the mempodroid exploit for Android based on a previous Linux exploit, mempodipper, by Jason A. Donenfeld (zx2c4). The mempodroid exploit uses this vulnerability to write directly to the code segment of the run-as program. This binary, used to run commands as a specifi c application UID, runs set-uid root on stock Android. Because run-as is statically linked on Android, the exploit needs the address in memory of the setresuid call and the exit function, so that the payload can be placed exactly at the right place. Sources for the mempodroid exploit are available at https://github. com/saurik/mempodroid. A more detailed case study of this vulnerability is provided in Chapter 8.
File Permission and Symbolic Link–Related Attacks
There are plenty of fi le permission and symbolic link–related attacks present in a range of devices. Most of them are introduced by custom OEM modifi cations that are not present in stock Android. Dan Rosenberg has discovered many of these bugs and has provided very creative root methods for a comprehensive list of devices in his blog at http://vulnfactory.org/blog/.
Initial versions of Android 4.0 had a bug in the init functions for do_chmod, mkdir, and do_chown that applied the ownership and fi le permissions specifi ed even if the last element of their target path was a symbolic link. Some Android devices have the following line in their init.rc script.
mkdir /data/local/tmp 0771 shell shell
As you can guess now, if the /data/local folder is writeable by the user or group shell, you can exploit this fl aw to make the /data folder writeable by replacing /data/local/tmp with a symbolic link to /data and rebooting the device. After rebooting, you can create or modify the /data/local.prop fi le to set the property ro.kernel.qemu to 1.
The commands to exploit this fl aw are as follows:
adb shell rm -r /data/local/tmp
adb shell ln -s /data/ /data/local/tmp
adb reboot
adb shell "echo 'ro.kernel.qemu=1' > /data/local.prop"
adb reboot
Another popular variant of this vulnerability links /data/local/tmp to the system partition and then uses debugfs to write the su binary and make it setuid root. For example, the ASUS Transformer Prime running Android 4.0.3 is vulnerable to this variant.
The init scripts in Android 4.2 apply O _NOFOLLOW semantics to prevent this class of symbolic link attacks.
Adb Restore Race Condition
Android 4.0 introduced the ability to do full device backups through the adb backup command. This command backs up all data and applications into the fi le backup.ab, which is a compressed TAR fi le with a prepended header. The adb restore command is used to restore the data.
There were two security issues in the initial implementation of the restore process that were fi xed in Android 4.1.1. The fi rst issue allowed creating fi les and directories accessible by other applications. The second issue allowed restoring fi le sets from packages that un under a special UID, such as system, without a special backup agent to handle the restore process.
To exploit these issues, Andreas Makris (Bin4ry) created a specially crafted backup fi le with a world readable/writeable/executable directory containing 100 fi les with the content ro.kernel.qemu=1 and ro.secure=0 inside it. When the contents of this fi le are written to /data/local.prop, it makes adbd run with root privileges on boot. The original exploit can be downloaded at http:// forum.xda-developers.com/showthread.php?t=1886460.
The following one-liner, if executed while the adb restore command is running, causes a race between the restore process in the backup manager service and the while loop run by the shell user:
adb shell "while ! ln -s /data/local.prop \ /data/data/com.android.settings/a/file99; do :; done"
If the loop creates the symbolic link in file99 before the restore process restores it, the restore process follows the symbolic link and writes the read-only system properties to /data/local.prop, making adbd run as root in the next reboot.
Exynos4: exynos-abuse
This vulnerability exists in a Samsung kernel driver and affects devices with an Exynos 4 processor. Basically, any application can access the /dev /exynosmem device fi le, which allows mapping all physical RAM with read and write permissions.
The vulnerability was discovered by alephzain, who wrote the exynosabuse exploit to demonstrate it and reported it on XDA-developers forums. The original post is available at http://forum.xda-developers.com/showthread.php?t=2048511.
First, the exploit maps kernel memory and changes the format string for the function handling /proc/kallsyms in order to avoid the kptr_restrict kernel mitigation. Then it parses /proc/kallsyms to fi nd the address of the sys_setresuid system call handler function. Once found, it patches the function to remove a permission check and executes the setresuid system call in user space to become root. Finally, it reverses the changes it made to kernel memory and executes a root shell.
Later, alephzain created a one-click rooting application called Framaroot. Framaroot embeds three variants of the original bug, which each allows unprivileged users to map arbitrary physical memory. This application works on devices based on the Exynos4 chipset and as well as devices based on the TI OMAP3 chipset. Most notably, alephzain discovered that Samsung did not properly fix the Exynos4 issue. He embedded a new exploit in Framaroot that exploits an integer overfl ow present in the Samsung fi x. This allows bypassing the additional validation and again enables overwriting kernel memory. These new exploits were silently included in Farmaroot by alephzain and later uncovered and documented by Dan Rosenberg at http://blog.azimuthsecurity.com/2013/02/re-visiting-exynos-memory-mapping-bug.html.
Diag: lit / diaggetroot
This vulnerability was discovered by giantpune and was assigned CVE identifi er CVE-2012-4220:
diagchar_core.c in the Qualcomm Innovation Center (QuIC) Diagnostics (aka DIAG) kernel-mode driver for Android 2.3 through 4.2 allows attackers to execute arbitrary code or cause a denial of service (incorrect pointer dereference) via an application that uses crafted arguments in a local diagchar_ioctl call.
The lit exploit used this vulnerability to cause the kernel to execute native code from user-space memory. By reading from the /sys/class/leds/ lcd-backlight/reg fi le, it was possible to cause the kernel to process data structures in user-space memory. During this processing, it called a function pointer from one of the structures, leading to privilege escalation.
The diaggetroot exploit, for the HTC J Butterfl y device, also used this vulnerability. However, on that device, the vulnerable character device is only accessible by user or group radio. To overcome this situation, the researcher abused a content provider to obtain an open fi le descriptor to the device. Gaining root using this method was only possible with the combination of the two techniques. You can download the exploit code at https://docs.google.com/file/d/0B8LDObFOpzZqQzducmxjRExXNnM/edit?pli=1.
Summary
Rooting an Android device gives you full control over the Android system. However, if you don’t take any precautions to fi x the open paths to gain root access, the system security can be easily compromised by an attacker.
This chapter described the key concepts to understand the rooting process. It went through legitimate boot loader unlock methods, such as the ones present in devices with an unlocked boot loader, as well as other methods that allow gaining and persisting root access on a device with a locked boot loader. Finally, you saw an overview of the most famous root exploits that have been used during the past decade to root many Android devices.
The next chapter dives into Android application security. It covers common security issues affecting Android applications and demonstrates how to use free, public tools to perform application security assessments.
