Re: Superuser unsanitized environment vulnerability on Android = 4.2.x
On Thu, Nov 14, 2013 at 7:44 AM, Gleb O. Raiko ra...@niisi.msk.ru wrote:
Considering ChainsDD Superuser you mentioned.
Unfortunately, your mail describes just potential attack vectors. While I
can't say for sure, Superuser isn't vulnerable at all, I'd like to note that
su invokes the am script in the process with the credentials of the caller,
not root. Thus, by manipulating the environment variables, file descriptors,
signals, etc, the user can get yet another process with the same
credentials, perhaps, with a shell or with an instance of Davlik VM inside.
Full disclosure: my testing so far has been mainly focused on SuperSU
and CWM Superuser on JB 4.2/4.3, mostly due to (perceived?) Superuser
market share and the fact that the respective developers responded to
my initial problem report.
I did not hear back from ChainsDD at all, and AFAICT the project is
abandoned. From what I've been able to piece together, it looks like
CM/AOKP users (~11-14 million[1][2]) are using the builtin CWM
Superuser, and most other active modders (~20 million) are using
SuperSU. Actual exploits were verified against these two projects.
But you brought up an interesting question, so let's take a look.
The easiest case to consider is JB 4.2: due to the new multiuser
features, am broadcast requires a special system permission[3] and
responds with this (not entirely accurate) message when run from e.g.
UID 10003:
W/ActivityManager( 413): Permission Denial: broadcast asks to run
as user -1 but is calling from user 0; this requires
android.permission.INTERACT_ACROSS_USERS_FULL or
android.permission.INTERACT_ACROSS_USERS
This is why CWM Superuser and SuperSU both execute am as root.
For the pre-JB-4.2 case, ChainsDD Superuser does drop privilege before
running am. Some random observations:
- su will block for a little while waiting to hear back from the Java
app, making it easy for us to hijack the sequence at just the right
time
- We have control over the parent's file descriptor for the socket
which the app uses to convey the verdict:
27495 unlink(/dev/com.noshufou.android.su/.socket27495) = -1
ENOENT (No such file or directory)
27495 bind(12, {sa_family=AF_UNIX,
path=/dev/com.noshufou.android.su/.socket27495}, 110) = 0
27495 listen(12, 1) = 0
[...]
27495 getgid32()= 10003
27495 setresgid32(0x, 0x2713, 0x) = 0
27495 getuid32()= 10003
27495 open(/acct/uid/10003/tasks, O_RDWR|O_CREAT, 0666) = -1
EACCES (Permission denied)
27495 mkdir(/acct/uid/10003, 0775)= -1 EEXIST (File exists)
27495 setresuid32(0x, 0x2713, 0x) = 0
27495 sigprocmask(SIG_BLOCK, [CHLD], []) = 0
27495 vfork() = 27496
[...]
27496 execve(/system/bin/sh, [sh, -c, /system/bin/am
broadcast -a 'com.noshufou.android.su.REQUEST' --es socket
'/dev/com.noshufou.android.su/.socket27495' --ei caller_uid '10003'
--ei allow '-1' --ei version_code '17' /dev/null], [/* 23 vars */])
= 0
- Not sure if I have up-to-date source code for this binary, but I've
seen at least one copy of activity.c that doesn't check the return
values from setresuid(), possibly leaving it open to a
rageagainstthecage-style attack[4]
- Perms on /dev/com.noshufou.android.su are 0750, with Superuser's uid/gid
- Superuser 3.2-RC3 has the android:debuggable flag set in the
manifest, so the shell user might be able to use run-as to hijack its
UID (3.1.3 doesn't)
- The socket has a highly predictable filename
- We have access to the intent's extra data from su, and can
manipulate it as desired
- The caller's UID is usually passed over the socket by trusted
code, but if you specify a version_code = 15, SuRequestActivity.java
will trust the data provided on the command line. This allows you to
spoof a request from any installed app, or even the Android System
So maybe try something like:
BOOTCLASSPATH= su -c id
ps | grep su
# note the PID and substitute below
/system/bin/am broadcast -a 'com.noshufou.android.su.REQUEST' --es
socket '/dev/com.noshufou.android.su/.socket27495' --ei caller_uid
'1000' --ei allow '-1' --ei version_code '15'
There is a bit of a social engineering component to this, so a malware
app would probably want to recognize the UIDs of well-known root
packages in order to maximize the odds that the user will approve the
request.
Can you think of a way to exploit ChainsDD Superuser without user
interaction on pre-4.2 devices?
[1] http://stats.cyanogenmod.com/
[2] http://stats.aokp.co/
[3]
http://insitusec.blogspot.com/2013/02/interact-across-users-permission-side.html
[4] http://dtors.org/2010/08/25/reversing-latest-exploid-release/
Android Superuser shell character escape vulnerability
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: 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: 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: 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.
Superuser su --daemon vulnerability on Android = 4.3
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
Superuser unsanitized environment vulnerability on Android = 4.2.x
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: echo -e '#!/system/bin/sh\nexport PATH=/system/bin:$PATH\ntouch /data/trojan.out\nexec $0 $@' 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.
