 So, very excited to bring up our next speaker, and I'm going to try this again. Jinjian? Jinjian die. Jinjian die. Awesome. So, he is going to talk about owning Android devices. How many people have Android devices? Yeah, be afraid. Be afraid. He's coming for your things. Let's give our next speaker a big round of applause. Have a great time, man. Thank you, Zhong. Hi, everyone. Today I will present how we pound the target's targets and won the luckiest boundary in the history of the SR program. Originally, my colleagues, Guanggong and Wenlin Yang, came to explain to you, but they could not come due to the visa. As we know, the pixel phone is protected by many layers of security. In the 2017 mobile Pound2on, Samsung, iPhone have been pounded many times, but only pixel was a survivor, no researchers, even to challenge it. But our team discovered a working explosion, which could comprise the pixel phone remotely. Because of the severity of our detailed report, we were awarded the highest reward in the history of the SR program. Next, I will show the details. First, introduce myself and my colleagues. I'm a secret researcher at 360, our team, and focused on Android system security research, vulnerability, hunting and exploiting. Guanggong, senior security researcher at our team, and he focused on Android and Chrome security research. He has spoken at several security conferences and the winner at many famous contests, like Pound2on, Pound2on Mobile. Wenlin Yang is a security researcher at 360, our team, and he focused on Android system security research. In this talk, I will introduce how we pound pixel. We use two bugs to pound pixel when we add engine bug to comprise the original, and the other is system server bug. That is used to escape thunderbolts and achieve elevation of private millage. I will show the details later. Here's my agenda. This speech includes three parts. How to exploit the re-add engine bug and then exploit the bug of system server process. Finally, we will make some conclusions. So, I will show the first part and introduce the shared revolver and the web assembly. And then, I will analyze the first bug of the exploit chain, CVE 2017, 5116, and then I will talk about how to exploit the vulnerability. Shared revolver object is used to represent a generic fixed-length rope binary data buffer, similar to the revolver object. We add 6.0 introduced support for shared revolver, a low-level mechanism to share memory between JavaScript workers and the synchronous-ness control flow across workers. Shared revolver gives JavaScript access to shared memory, atomics, and funtics. Shared revolver also unlocks the ability to post-straight applications to the web, asm.js, or web assembly. Unfortunately, shared revolver was dissembled by default in all major browsers on January 2018 in response to melaton and spec tree. But we reported the bug on July 2017, so not affected. Maybe the web will be enabled in the future. It's worth paying attention to. Web assembly is a new type of code that can be run in the modern web browsers. It is a low-level assembly like language with a compact binary format that runs with near native performance and a profile language such as C or C++ with a complication tagging so that they can run on the web. It is also designed to run alongside JavaScript, allowing both to work together. Here is an example how to invoke the function that is from the simple .wssm file. Okay, I introduced some basic knowledge, and I will analyze the web eight-bug in detail. The vulnerability was fixed in Chrome 61, down 0, down 61, 63, 79. So from 60 to person primary, this may be effect. By combining the three features, shared array and buffer, web assembly and a web worker in Chrome, and OOB access can be triggered through a rest condition. Simply speaking, web assembly code can be put into a shared array buffer and then transferred to a web worker. Then the main street persists the web assembly code. The worker street can modify the code at the same time, which causes an OOB access. Here's the bucket code. The bucket is in the function, get first arguments as best. Where the arguments are just maybe an array buffer or typed array object. After a shared array buffer is imported to JavaScript, a typed array can be backed by a shared array buffer. So the content of the typed array can be modified by other work threads at the same time. Here's a POC. The worker threads modify the web assembly code at the same time. Another thread is parsing the code. The web assembly code is put into a shared array buffer then a typed object is created using the shared array buffer as a buffer. After that, a worker thread is created and the shared array buffer is passed to the newly created worker thread. While the main thread is parsing the web assembly code, the worker threads modify the shared array buffer. After the main thread's bound check, the instruction core zero can be modified by the worker thread to core 128 and then be parsed and compiled by the main thread. So OOB access occurs. The last part is the assembly code. The instruction core zero was modified to core 128 making OOB access. The core zero instruction can be modified to core any other web assembly function. So the exploration of this bug is straightforward. If core zero is modified to core dollar leak, registers and stack of contents are dumped to web assembly memory because function zero and function dollar leak have a different number of arguments. This results in many useful pieces of data in the stack being leaked. Sorry. We cannot modify the instruction core zero. Any core function x instruction can be modified. Assume function x is a WSM function with six arguments as shown above. When we add complied the function x in IS 32 architecture, the first five arguments are parsed through the registers and the sixth argument is parsed through stack. All the arguments can be set to any value by JavaScript. So when a JavaScript function calls a web assembly function, we add complied Chris or JS to WSM function internally. After completion, the JavaScript function will call JS to WSM function and then JS to WSM function will call the web assembly function, JS to WSM function use different core convention. Its first argument is parsed through stack. So if we modify core function x to call JS to WSM function, what will happen? The JS to WSM function will check the sixth arguments of function x as its first argument but it takes its first argument as an object pointer so type confusion will be triggered when the argument is parsed to the two number function. This means we can pass any values as an object pointer to the two number function. Thus, we can fake a revolver object in some address such as in a double array and pass the address to number function. Exploits of an OOP access in v8 is straight forward usually through these few steps. leak a revolver's content and then fake an revolver a double array by using leaked data. Next, pass, fake a revolver's address to number. Modify back in store and pass a length of the revolver in core back. Get arbitrary memory read and write and finally override JIT code with cell code. A lot of researchers have talked about the exploiting methods. I will not explain this in detail. Hit the patch, just copy the revolver assembly code and to parse without using shared memory. Next, I will talk about the second bug of the full exploit chain. Analyze the bug and introduce a way to escape center box and show how we exploit the bug. The center box escape bug is caused by map and on map mistake and caused a use after on map use you. The bug is called in the function G relic map and G relic on map both functions are in lab gallery model. G relic map maps a graphic buffer to memory space. Graphic buffer is controlled by the arguments handler but the handler pointer is controlled by crew renderer process. While mapping, the map address plus an offset and is assigned to a base pointer. The map memory will be on mapped in function G relic on map. Let's have a look. When on mapping, base pointer is passed to system core on map directly without minus the offset. The offset is not used at all. As a result, map on our map are mismatched. However, the member offset can be manipulated from a crew's center box process. So it's possible to on map any pages in system server from crew's center box renderer process. We have achieved RCE but if you want to trigger the system server bug from the crew we have to bypass the center box. Then I will introduce a way to escape center box. In the picture we can see that crew is a center box the process belong to isolated app domain. From the SE police file of isolated app, a view service like activity service can be got in center box process. Although we can get activity service from the center box process, then when starting activity function inverse not isolated caller will be invoked. We should check if the caller is in isolated app domain. Because of SE Linux, most system service have been restricted to access from center box process and view and viewer functions can be called in the isolated app domain. Attack service is getting narrow. From the close we can see that. Despite various restrictions we will still find a ingenious way that can get renderer process reach system server by bounding core, bounder core with password object. A lot of classes implement the interface password. The member function creates from password of all these classes can be called from crew's center box using bounder core. Graphic buffer is that one. It's used in the exploration. I will talk about it later. This is the case. To reach system server avoiding inverse not isolated caller and it's a remote transact by bounder core. The bounder be passed from renderer is passed in activity options constructor. So we get away to reach system server from crew. Core creates from password to create a bounder encapsulated with a graph buffer and call the bounder method conferred to translucent and pass the miniatures bounder to system server. Exploit bug. We complete the exploit through the six steps above. Next, I will detail each step. Step one, address space champagne. We make the address space lay out look at the show above. A heap trunk is right above some continuous or shared memory mapping. Step two, track the bug on my part of heap and share a shared memory on my four kilo bus in heap trunk and two million to two million minus fourth KB in shared memory. Shared memory 29. So there is two M gap between heap trunk and share memory 29. Step three, fill the amount space with an SH memory. The gap is filled with shared memory 1001. Step four, spray the heap. The heap data will be writing to the shared memory. The heap manager believes the memory range between the two red address is still mongered by it and where allocates memory from this range. Resulting heap data is writing to a shared memory. Step five, allocate graphic buffer objects in a shared memory over write feature function pointer. Because the field of shared memory in step three is mapped both by system server and renderer process. Partial heap of system server can be read and written by renderer process and we can trigger system server to allocate some graphic buffer object in a shared memory. We can read virtual table of graphic buffer object and overwrite the visual function pointer by writing the shared memory. Step six, as graphic buffer is inherited from REF base which has a member function named on last strong REF we can read the virtual table address from a shared memory and then can calculate the address of function on last strong REF. We found some ROPS chains in lab UI and modified the virtual table of graphic buffer to trigger ROP. When a graphic buffer object is deconstructed the virtual function on last strong REF is called. So we can replace this visual function to jump to ROP. When GC happens the counter flow goes to ROP. Okay. Finally let's summarize the contents of this talk. First we compare the Chrome render row with with edge bug and then we achieve getting the privilege of system server by using an ingenious way to escape standard bugs and exploiting the bug CVE 2017 1, 4, 9, or 4. Combine both. We complete the four remote exploits chain. All of these bugs have already fixed security updates of December 2017. Thanks to all colleagues at our team and core team. That's all. Thank you.