Google finds a major Android security vulnerability in 360

Google finds a major Android security vulnerability in 360

On July 15, January 22, Beijing time, the media communication meeting on vulnerabilities of the "shoot through the cloud" combination was held at building 360. Last week, Google officially issued a message to acknowledge the 360 Alpha Team and awarded the android vulnerability Rewards Program (ASR), which totaled $360, to the 112500 Alpha Team Leader Zang Guang. In 360, the Alpha team submitted a vulnerability report on how to break the Pixel mobile phone's "flying Arrows" combination to Google.

Google makes a huge deal of money and asks security companies to pick up the wrong ones

The Android Security Rewards (ASR) project was launched by Google in 2015 and is mainly used to reward Security experts who submit Android Security vulnerabilities to the company. This project requires experts to test Pixel mobile phones and tablets running the latest Android version, and then provide different bonuses based on the severity of vulnerabilities.

The project received strong support from security experts and white hats in June 2017, but Google said: "Each Android version includes more security protection, however, no experts have won the vulnerability chain top prize in two years." But last Friday, the company finally announced that Guang Gong from Qihoo's 360 technology company won the prize, totaling $0.1125 million (about 0.72 million RMB ).

Figure: the Google team issued a ticket to the 360 team

According to the 360 security team, the two vulnerabilities found are based on Chrome V8 engine vulnerability CVE-2017-5116, and Android system vulnerability CVE-2017-14904, ASR is the first series of vulnerabilities that can be effectively exploited remotely. The Chrome browser vulnerability CVE-2017-5116 can be used to remotely execute code in the Chrome browser sandbox.

The combined vulnerabilities of "go through the cloud" can completely break through Google's Pixel mobile phone remotely, posing a great threat to users' privacy and property security. To protect users' mobile phone security, the 360 Alpha team reported the vulnerability to Google in August, and successfully helped them fix Android and Chrome browsers.

Figure: 360 on-site speech by Zheng Wenbin, Assistant President and Chief Security Engineer

The reason why Google will issue such a high bonus this time is that, on the one hand, because of the wide impact of the vulnerability of the "flying Arrows" combination, most Android phones may be cracked by hackers before the vulnerability is fixed. On the other hand, this vulnerability is based on the underlying system and can affect all applications on mobile devices, even basic applications such as phone and SMS, causing the greatest harm. Criminals can exploit this vulnerability to obtain text message verification codes and pay application permissions of users, which poses a great threat to users' privacy and property.

Technical details of Pixel remote exploitation chain

According to Google's online security document, we found technical details about these two vulnerabilities.

The vulnerability chain includes two vulnerabilities, CVE-2017-5116 and CVE-2017-14904. The CVE-2017-5116 is a V8 engine error that is used to get remote code execution during sandbox rendering. CVE-2017-14904 is a vulnerability in the libgralloc module of Android that is used to transfer from the Chrome sandbox. By accessing the malicious URL in Chrome, this chain can be used to inject arbitrary code into system_server.

RCE error (CVE-2017-5116)

V8 6.0 introduces support for SharedArrayBuffer. SharedArrayBuffer is a low-level mechanism that shares memory among JavaScript staff and synchronizes control flows between them.

SharedArrayBuffers gives JavaScript access to shared memory, atoms, and futexes. WebAssembly is a new type of code that can be run in modern Web browsers. It is a low-level assembly language and has a compact binary format, which can be similar to the performance of the local machine, it also provides assembly language (such as C/C ++) goals so that they can run on the Internet. By combining the SharedArrayBuffer WebAssembly and web worker functions in Chrome, OOB access can be triggered through competition conditions. In short, the WebAssembly code can be put into SharedArrayBuffer and passed to the Web Worker. When the main thread parses the WebAssembly code, the working thread can modify the code at the same time, which leads to OOB access.

The multi-function code is located in the GetFirstArgumentAsBytes function. The args parameter may be an ArrayBuffer or TypedArray object. After SharedArrayBuffer is imported to JavaScript, TypedArray may be supported by SharedArraybuffer. Therefore, the content of TypedArray may be modified by other worker threads at any time.

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);}

EoP (CVE-2017-14904) Error)

The Sandbox escape error is caused by the mismatch between map and unmap, which leads to the Use-After-Unmap problem.

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 || mappedAddress == MAP_FAILED) { ALOGE("Could not mmap handle %p, fd=%d (%s)", handle, hnd->fd, strerror(errno)); return -errno; } hnd->base = uint64_t(mappedAddress) + hnd->offset; //---> save mappedAddress+offset to hnd->base } else { err = -EACCES;}…… return err;}

Gralloc_map maps the graphic buffer controlled by the parameter handle to the memory space, while gralloc_unmap unmaps it. During ing, mappedAddress plus hnd-> offset is stored in hnd-> base. However, when unmapping is enabled, hnd-> base is directly transferred to the system to call unmap minus the offset. Hnd-> offset can be operated from the Chrome sandbox process, so you can unmap any page in system_server from the Chrome sandbox rendering 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 limits the isolation_app domain to access most Android system services, isolated_app can still access three Android system services.

52neverallow isolated_app {53 service_manager_type54 -activity_service55 -display_service56 -webviewupdate_service57}:service_manager find;

To trigger the previously mentioned Use-After-Unmap error from the Chrome sandbox, first put a resolvable GraphicBuffer object into a package, call the binder method convertToTranslucent of IActivityManager to pass the malicious package to system_server. This error is triggered when system_server processes this malicious software package.

360 join hands with the mobile security alliance to launch the "pioneer" action

Currently, Android users account for more than 50% of mobile phone users in China, which is very large. However, due to the release delay of patches, the Android mobile phone on the market may suffer from a relatively lagging vulnerability fix. Most mobile phone manufacturers are waiting for official Google patches to fix Android system vulnerabilities. However, when a white hat system discovers a vulnerability and submits it to Google, Google receives a vulnerability report to fix the vulnerability. It takes a relatively long time for the company to issue a patch to the vendor. During this period, mobile phone users often face certain security threats due to various vulnerabilities.

In October December 2017, China Information and Communications Research Institute Thiel terminal lab jointly established Mobile Security Alliance (MSA) with equipment manufacturers, Internet vendors, Security vendors, and institutions of higher learning ).

Therefore, as 360 of the members of the Mobile Security Alliance, they joined hands with the mobile security alliance to launch the "Pioneer" Action. Together with the mobile security alliance, helping Chinese mobile vendors become "pioneers" in vulnerability fixing ".

Figure: Live speech by Dr. Yan Shijun, head of the standard Policy Group of the mobile security alliance

In the future, the "pioneer" action will cooperate with the mobile security alliance's vulnerability repair plan, and 360 share the vulnerability information with the mobile security alliance members immediately upon discovery, actively promotes policies, standards, detection, repair, and emergency response, works with partners to determine vulnerability risks, and works out defense plans to fix vulnerabilities in the shortest time.