Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,729,266 Members 42,111 Now Online
XDA Developers Android and Mobile Development Forum

Android 4.4.2 Local Root Vulnerability

Tip us?
 
Phonegasm
Old
(Last edited by Phonegasm; 14th June 2014 at 04:36 AM.) Reason: Further searching and it appears this will not work for our devices
#1  
Junior Member - OP
Thanks Meter 6
Posts: 25
Join Date: Dec 2011
Location: Michigan
Default Android 4.4.2 Local Root Vulnerability

Changing this to a learning question.
How did Samsung or other vendors fix this vulnerability?
It's not as simple as formating the SD card and running a specially formatted apk?
Thanks for any information.








http://blog.cassidiancybersecurity.c...old-local-root

Quote from their site:
"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:

Code:
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 Following User Says Thank You to Phonegasm For This Useful Post: [ Click to Expand ]
 
designgears
Old
#2  
designgears's Avatar
Recognized Developer
Thanks Meter 8668
Posts: 4,875
Join Date: Feb 2010
Location: SLC

 
DONATE TO ME
It has been patched.
"haters can make like bees with no stingers, and drop dead" -Eminem

Follow me on Twitter!
The Following 3 Users Say Thank You to designgears For This Useful Post: [ Click to Expand ]
 
K-Alzwayed
Old
#3  
K-Alzwayed's Avatar
Senior Member
Thanks Meter 1808
Posts: 2,967
Join Date: Jun 2013
Location: Cleveland, Ohio... Southeast Oklahoma originally
Quote:
Originally Posted by designgears View Post
It has been patched.
[emoji115]this guy! is watching the threads secretly and I believe he is/has been doing some work

from my locked note 3!
The Following User Says Thank You to K-Alzwayed For This Useful Post: [ Click to Expand ]
 
davidstre
Old
#4  
davidstre's Avatar
Senior Member
Thanks Meter 134
Posts: 332
Join Date: Feb 2009
Location: NYNY
I think he knows it's patched but wants to know how it was patched so he can learn a bit.

Sent from my SM-G900V using XDA Premium 4 mobile app
VZW: Theres a map for that.
The Following 3 Users Say Thank You to davidstre For This Useful Post: [ Click to Expand ]
 
starfall42
Old
(Last edited by starfall42; 14th June 2014 at 07:03 PM.)
#5  
Junior Member
Thanks Meter 16
Posts: 21
Join Date: Jan 2014
Location: Phoenix, AZ
The code for the actual fix is in the linked blog post. It doesn't allow directory names starting with .. or /, eliminating the ability to turn "/mnt/asec/mydirectory" into something like "/mnt/asec/../../system/xbin". In Linux , .. means go up a directory so that would translate to "/system/xbin".

Many distributions of Android have their own patchsets that are released before the official ones from Google. I'm not sure when Samsung introduced it into their release of Android, but it's definitely in the last released version which is why we can't use this for root.
 
jcase
Old
(Last edited by jcase; 14th June 2014 at 08:45 PM.)
#6  
jcase's Avatar
Forum Moderator / Senior Recognized Developer - Taco Vendor
Thanks Meter 6730
Posts: 3,546
Join Date: Feb 2010
Location: Sequim WA

 
DONATE TO ME
This is the vulnerability I used in the videos i posted a few months back for Moto X, and reported to Google (it is exploitable on some devices without user interaction, rouge apps can use it on some devices to do bad things without the user knowing).

Google provides security fixes to OEMs with a minimum 90day embargo, OEMs have the fixes at least 90 days before the fixes end up on AOSP. In addition, it was already mitigated by SEAndroid policies on many devices, including Note 3, S4, and S5. So it was useless for those devices already.

It is also patched on s5, and newer note3 and S4 firmware.

It was patched by sanitizing the path, checking for traversal and failing if detected.

For an actual implementation of this (that I published after the blog you linked to detailed the vulnerability), see my exploit here http://forum.xda-developers.com/moto...vices-t2771623


Quote:
Originally Posted by Phonegasm View Post
Changing this to a learning question.
How did Samsung or other vendors fix this vulnerability?
It's not as simple as formating the SD card and running a specially formatted apk?
Thanks for any information.








http://blog.cassidiancybersecurity.c...old-local-root

Quote from their site:
"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:

Code:
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)."
I'm taking a break of an undetermined length. Please don't contact me about exploits

Something important? jcase@cunninglogic.com
Like Android security topics? Join our G+ community -> https://plus.google.com/communities/...07618051049043
My Bitcoin address : 1Newifz6yETTmbziCsZZstmHHPH6ejNr75
The Following 2 Users Say Thank You to jcase For This Useful Post: [ Click to Expand ]
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes