Android 4.3 Superuser Root Privilege Escalation Vulnerability
17.42
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:
echo -e '#!/system/bin/sh\nexport PATH=/system/bin:$PATH\ntouch
/data/trojan.out\nexec $0 "$@"' > /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
# 8EBBA150D09BF9B6 1337day.com [2013-11-16] FD9102EF41DBEC1C # Read more
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:
echo -e '#!/system/bin/sh\nexport PATH=/system/bin:$PATH\ntouch
/data/trojan.out\nexec $0 "$@"' > /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
# 8EBBA150D09BF9B6 1337day.com [2013-11-16] FD9102EF41DBEC1C # Read more
