SBN

SSD Advisory – Chrome AppCache Subsystem SBX by utilizing a Use After Free

Vulnerabilities Summary
The vulnerability exists in the AppCache subsystem in Chrome Versions 69.0 and before. This code is located in the privileged browser process outside of the sandbox. The renderer interacts with this subsystem by sending IPC messages from the renderer to the browser process. These messages can cause the browser to make network requests, which are also attacker-controlled and influence the behavior of the code.

Vendor Response
Vendor has fixed the issue in Google Chrome version 70.

CVE
CVE-2018-17462

Credit
Independent security researchers, Ned Williamson and Niklas Baumstark, had reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program.

Affected systems
Google Chrome Versions 69.0 and before.

Vulnerability Details
The vulnerability exists in the AppCache subsystem in Chrome. The buggy code is accessible with IPC messages from the renderer process to the broker process.AppCache is a reference-counted object. It is possible to trigger the RemoveCache function while the object is being destructed, thus incrementing the reference-count of freed object by N.

Notice that newest_complete_cache is the destructed object. A fix is possible by calling CancelUpdate after setting the newest_complete_cache to be NULL.

Further exploiting is achieved by decrementing an object reference-count to 0. Once a reference is taken to the object and being destroyed, the reference-count would reach 0 and the object would be freed, thus creating a stronger use-after-free. (should be called type confusion?)

Exploit
This bug provides us two essential primitives: use-after-free decrement-by-N of the first dword of the freed object, where N is controlled. If in the process of decrementing, the first dword reaches 0, the AppCache destructor is called and the pointer is freed.

We use these primitives in two stages: first, to construct a leak, and second, to trigger code execution. The freed AppCache object has size 0xA0 bytes. We found that net::CanonicalCookie has the same size, so we can spray cookies in the browser process by making a network request and including cookies in the response.

std::string name is the first object in the CanonicalCookie. This name is the key from the key/value pair name=value from the cookie string. On Windows STL, the first qword of a std::string object is a pointer to the string data. By using decrement-by-N, we leak a number of bytes by reading the cookie back from the browser and scanning the name field. This leak gives us a heap address, which allows us to spray the heap and predictably place controlled data at a now-known address.

To achieve code execution, we produce a single dangling reference to a freed AppCache via the described vulnerability. We reclaim it with a blob of the same size, forging a reference count of 1 and a fake AppCacheGroup with reference count 0. Once we remove the dangling reference and enter the AppCache destructor, the else branch of the RemoveCache method will cause the AppCacheGroup to be freed due to its reference count going from 0 to 1 and back to 0.

The AppCacheGroup destructor in turn performs a virtual call, which
we fully control.

Due to the once-per-boot ASLR approach of Windows, all modules are loaded
at the same address in the renderer and broker process. We use a gadget
from __longjmp_internal to bootstrap the ROP. From there we can either
jump to shellcode or open notepad.

*** This is a Security Bloggers Network syndicated blog from SecuriTeam Blogs authored by SSD / Ori Nimron. Read the original post at: https://blogs.securiteam.com/index.php/archives/3786