Ask anybody that spends time in the security circles and they'll tell you that every large software project is bound to have a few long-standing vulnerabilities in the code. Fortunately, there are usually a few people who are paid to close up those holes so you, the customer, don't find yourself the victim of nefarious evildoers someday. Like so many before it, the latest update to Android came with a boatload of changes, at least one of which fixes a potentially dangerous vulnerability that can be used for numerous attacks, including a way to acquire root.

The Vulnerability

As described in a post on the Cassidian CyberSecurity blog, the vulnerability exists in a system component known as VOLD (Volume Management daemon). Its responsibility is to "create and maintain a file system image rooted at root-dir that contains symbolic names for removable media." As far as most Android users will be concerned, this is the part of the OS that takes care of mounting your SD card and creating the /sdcard path. In addition to this basic task, it is also used for mounting virtual filesystems, including a special type called ASEC (Android Secure External Caches). These ASEC files are tiny encrypted filesystems intended for use by individual apps, giving them a convenient way to securely store data on otherwise insecure volumes, like a removable SD card.

The exploitable weakness in VOLD is in the command that's used to mount one of these ASEC files. At no point did Android check to ensure that the path passed in by a user is entirely valid. An attacker can pass in a relative path to a location that already exists, and the VOLD will grant write access to that filesystem. There are several limitations to this, but it's an extremely powerful way to manipulate the files belonging to other apps or even the operating system.

The Fix

A patch (0de7c61) for the issue was quickly identified after source code for Android 4.4.3 was uploaded to AOSP on Monday. Google's fix for the issue was to simply install a check in VOLD to confirm that any path passed into the method calls do not include symbols ('..' or '/') that are used to redirect the path from the predefined mounting location. Since this path went live, quite a few security researchers have commented that the vulnerability was fairly old and well-known in their circles.

A Temp-Root Method

Among the security specialists to speak out on the issue, Justin Case has shared a working exploit capable of acquiring "tethered root" on a number of Motorola devices. This is a temporary method that must be run from a computer (using adb) and reverts to an unrooted state when the device shuts down or reboots. This exploit is customized for Motorola brand devices, and will only work on those running 4.4.2 and earlier. The basic method will also work on several other models, but some devices like the LG G3, HTC One m8 (just the latest OTAs), and many Samsung handsets have already backported this fix to their models running on 4.4.2.

Tethered root isn't mentioned very often in the Android community, but it has been a fairly common part of hacking history for iOS users, who refer to it as "tethered jailbreak." Being tied to a computer to enable root isn't the most convenient option, and it would surely interfere with a few of the popular use cases for rooting, but it can be handy if you only need occasional access (e.g. backing up app data). This is also a decent alternative if you're trying to avoid incrementing the flash counter or triggering the tamper flag on newer devices. This particular exploit also lacks the ability to enable write access to /system, which means many common tweaks aren't possible, like those that depend on modifying the build.prop file.


Due to the age and moderately widespread awareness of this bug, some people suspect it may have already been exploited maliciously in the wild. While there really aren't practical ways to completely prevent this attack on devices that will never receive any more updates, the methods to execute it are fairly limited without using multiple exploits.

Source: Cassidian CyberSecurity, Pie for Motorola (by Justin Case)