http://blog.cassidiancybersecurity.com/post/2014/06/Android-4.4.3%2C-or-fixing-an-old-local-root
介绍了Android 4.4.2本地提权漏洞出现的原因以及利用方法.
http://forum.xda-developers.com/moto-x/orig-development/root-4-4-x-pie-motorola-devices-t2771623
一个家伙发布了该漏洞在摩托罗拉手机上提权的EXP程序.
————————————————–\
Google has just released Android 4.4.3 version in AOSP (Android Open Source Project). The Funky Android website has published the whole changelog between versions 4.4.2 and 4.4.3.
This time, it seems Google has fixed an old vulnerability, allowing to elevate privileges from an application with a few permissions to root, on any Android version supporting Android Secure External Caches (ASEC).
Looking at the previously linked changelog, one can notice the following fix in the vold daemon:
Project: platform/system/vold 0de7c61 : Validate asec names.
Vold (Volume Management Daemon) is a daemon running as root, which main goal is to handle removable media devices. ASEC are secured containers allowing applications to securely store data on the SD card, and have been introduced back in 2010. These containers have been created because the SD Card filesystem (VFAT) does not allow privileges separation.
ASEC are simple files containing a ciphered filesystem, which is unciphered and mounted with permissions for a specific UID (and therefore for a specific application). The ASEC files (extension “.asec”) are stored on the SD Card or in the “/data” folder, and mounted in a subfolder of “/mnt/asec”.
Vulnerability
The creation of the ASEC file is performed by the following code, in VolumeManager.cpp:
const char *asecDir = isExternal ? Volume::SEC_ASECDIR_EXT : Volume::SEC_ASECDIR_INT; int written = snprintf(asecFileName, sizeof(asecFileName), "%s/%s.asec", asecDir, id);
The mount point for the newly created asec is then defined as follows:
int written = snprintf(mountPoint, sizeof(mountPoint), "%s/%s", Volume::ASECDIR, id);
The vulnerability here is rather obvious: there is no check on the “id” variable, which is the name given by the user to its ASEC container. It is therefore possible to perform a basic path traversal, to create the ASEC file and its mount point in a different directory than expected, as for example one the “attacker” can write into.
The following code is then responsible for the creation of the mount point:
if (mkdir(mountPoint, 0000)) { if (errno != EEXIST) { SLOGE("Mountpoint creation failed (%s)", strerror(errno)); if (cleanupDm) { Devmapper::destroy(idHash); } Loop::destroyByDevice(loopDevice); unlink(asecFileName); return -1; } } [...] mountStatus = xxx::doMount(dmDevice, mountPoint, false, false, false, ownerUid, 0, 0000, false);
This means that if the mount point already exists, no error is raised, and the container is correctly mounted in “mountPoint”. Guess what? If “mountPoint” already exists AND is a symlink to an existing directory, the ASEC container will be mounted over this directory. And the user will have full access to it, allowing him to write new files inside.
There are many ways of exploiting this vulnerability to gain root privileges.
Last detail about this vulnerability: it requires permissions to create ASEC containers. The “shell” user, as used by adb, has the requiered privileges. For the vulnerability to be exploited from an application, it needs the ASEC_* permissions (such as ASEC_CREATE).
The Fix
Google has now added a call to a new function “isLegalAsecId()” at the beginning of each function dealing with ASEC ids. The code of the function is the following:
bool VolumeManager::isLegalAsecId(const char *id) const { size_t i; size_t len = strlen(id); if (len == 0) { return false; } if ((id[0] == '.') || (id[len - 1] == '.')) { return false; } for (i = 0; i < len; i++) { if (id[i] == '.') { // i=0 is guaranteed never to have a dot. See above. if (id[i-1] == '.') return false; continue; } if (id[i] == '_' || id[i] == '-') continue; if (id[i] >= 'a' && id[i] <= 'z') continue; if (id[i] >= 'A' && id[i] <= 'Z') continue; if (id[i] >= '0' && id[i] <= '9') continue; return false; } return true; }
This forbids the use of “..” and “/” in the ASEC ids, which fixes the path traversal attacks.
Conclusion
Google has fixed a very old local root vulnerability. We have evidences that this vulnerability was known, and it might already have been exploited in the wild by bad guys. Android is becoming more and more secure as Google introduces modern security mechanisms, but old code still needs to be fully audited to eradicate these 90’s security vulnerabilities.
———————————————————————————\
Changelog
1.1 – doh fixes a bug where exploit only works once. Pie is a root for motorola devices, should work up to and including 4.4.2. I had hoped to save this until August however the bug was outed with 4.4.3, and detailed publicly by several people. It now has no value for my purposes. Sucks for me, great for you. Vulnerability details: This is a tethered root (think tethered jailbreak), meaning you have to run it each time you reboot in order to have root access. You do not get system write access, you do get root and busybox. Usage: Code:
adb push pie.jar /data/local/atvc adb push root.sh /data/local/atvc adb shell chmod 755 /data/local/atvc/root.sh adb shell /data/local/atvc/root.sh Expected output: Code:
Retina:package jcase$ adb push pie.jar /data/local/atvc 5288 KB/s (1538203 bytes in 0.284s) Retina:package jcase$ adb push root.sh /data/local/atvc 81 KB/s (137 bytes in 0.001s) Retina:package jcase$ adb shell chmod 755 /data/local/atvc/root.sh Retina:package jcase$ adb shell /data/local/atvc/root.sh pie by jcase want to buy me pie? paypal-> jcase@cunninglogic.com Retina:package jcase$ adb shell shell@ghost:/ $ su root@ghost:/ # id uid=0(root) gid=0(root) context=u:r:kernel:s0 Busybox license -> http://www.busybox.net/license.html FAQ: Will it work on LG G3, Samsung <model>, Nexus 5? Will you root X? You suck! This doesn’t work, will you help me? Will you make this work on X? Will you do this for me? This doesn’t work! Will you X? What is your favorite pie? I’m taking a break of an undetermined length. Please don’t contact me about exploits
Something important? jcase@cunninglogic.com |
|