Google looks at bypass in Chromium’s ASLR security defense, throws hands up, won’t patch garbage issue

In early November, a developer contributing to Google’s open-source Chromium project reported a problem with Oilpan, the garbage collector for the browser’s Blink rendering engine: it can be used to break a memory defense known as address space layout randomization (ASLR).

About two weeks later, Google software security engineer Chris Palmer marked the bug “WontFix” because Google has resigned itself to the fact that ASLR can’t be saved – Spectre and Spectre-like processor-level flaws can defeat it anyway, whether or not Oilpan can be exploited.

Or as Palmer put it, “we already have to plan for a world in which ASLR is bypassable.”

On Wednesday, Chromium’s bug tracking bot lifted the curtain on the previously private discussion and made it publicly accessible.

Security researchers have been warning about the shortcomings of ASLR for years. The defense mechanism works by placing parts of software in randomly selected regions of the code’s memory address space, and these positions change every time the software is started. This makes life hard for those writing malware that exploits vulnerabilities in applications and operating systems: the miscreants can’t be sure where components needed to attack the code are located in memory, and their exploits will fail to work.

But, as we said, ASLR is not bombproof. It simply increases the barrier miscreants have to jump over before they can hack a victim’s system. In a 2017 paper, Vrije Universiteit Amsterdam researchers wrote, “ASLR is fundamentally flawed in sandboxed environments such as JavaScript and future defenses should not rely on randomized virtual addresses as a building block.”

That sentiment is now reflected in Chrome as a WontFix bug.

Garbage collection in the context of software refers to automatic memory management – the process of identifying data in memory that is no longer in use, and allowing that occupied memory to be reused for other things. As a garbage collector, Oilpan performs this task by scanning memory for references to other data in memory. Any data that’s no longer referenced by other data is garbage ripe for collection. But memory is basically a huge array of numbers, and so Oilpan has to figure out if a value in memory is a reference to data or just a value, like a share price or the color of pixel.

Oilpan relies on an approach known as conservative garbage collection, which makes some effort to distinguish between pointers and integers but doesn’t rely on techniques that incur a relatively high resource cost, such as using tags to distinguish between the two types of data.

As the individual reporting the bug observed, this approach opens the door to a way to find the location of objects in memory, which is what ASLR is designed to prevent.

“As [Oilpan] can’t distinguish integers from pointers, if an integer points to an allocated object, it just assumes that it’s a valid pointer and marks the object” as in use, the bug reporter explains. “Using this property, we can find out if some object is located at the given address.”

The technique for doing so involves allocating an object – which is placed in memory at a location we don’t know – putting an address to query into an area of memory called the stack, removing all references to the object, and triggering garbage collection. If the target object survives, the queried address points to it.

Memory layout is thus revealed, making exploitation efforts easier.

The bug reporter crafted a Javascript proof-of-concept exploit that incorporates WebAssembly code to fill the stack with pointers and try to free the target object. Mitigation of the technique requires the use of APIs to force garbage collection, according to Richard Johnson, a principal security researcher at Fuzzing.io.

Pretty much game over

An industry security professional who asked not to be identified told The Register that ASLR has been trivial to bypass for some time and anyone who writes exploits understands that. “This is cool because the researcher abused garbage collection and the WASM sandbox to bypass ASLR,” the infosec bod said. “Basically, they abuse security features to bypass another security feature.”

Apple’s Safari, which relies on WebKit’s Riptide garbage collector, also employs a conservative approach and is said to be affected. Firefox, however, appears to have been spared.

“Browsers can’t really fix CPU issues, we can only mitigate the impact,” wrote Johnathan Norman, Microsoft Edge vulnerability research lead, in a tweet. “There are limits on what we can do. There are a number of issues that remain unaddressed by Intel/AMD.”

Those issues have to do with speculative-execution design flaws in modern chip architectures, many of which haven’t entirely been mitigated. Following the revelation of the related data-leaking Spectre family of bugs in 2018, Google’s browser security guidance more or less acknowledged that assumptions would have to be rethought.

“We must assume that active web content (JavaScript, WebAssembly, Native Client, Flash, PDFium, …) will be able to read any and all data in the address space of the process that hosts it,” the biz says in a summary of the situation.

“Multiple independent parties have developed proof-of-concept exploits that illustrate the effectiveness and reliability of Spectre-style attacks. The loss of cross-origin confidentiality inside a single process is thus not merely theoretical.”

Coincidentally, the WontFix bug also turns out to be a WontPay bug: Google’s Vulnerability Reward Program reviewed it and decided not to offer any reward. ®

READ MORE HERE