Amster-damn, that’s a hell of a vulnerability to make browser bug exploitation easier.
Researchers in Europe have developed a way to exploit a common computer processor feature to bypass a crucial security defense provided by modern operating systems.
By abusing the way today’s CPUs manage system memory, an attacker can discover where software components, such as libraries and RAM-mapped files, are located in virtual memory. With these locations in hand, malicious code can find and use particular instructions and data within these components to start hijacking a computer system.
Specifically, the researchers have shown how to defeat address space layout randomization (ASLR). This is a mechanism provided by operating systems – from Windows and Linux to macOS and the BSDs – that randomly places each application’s dependencies in their virtual memory spaces. This makes it tough for attackers to run exploit code that expects widgets of code and data in specific spots in memory. Without the base addresses for these components, attackers are blindfolded and their hack attempts usually fail.
If naughty code – such as JavaScript running on a malicious webpage – can discern where these libraries and other objects are positioned at runtime, a follow-up exploit on the page can use this leaked information to reliably attack browser bugs and move onto the next stage of the intrusion: usually this involves performing system calls to spawn new processes, download payloads, and gain control of the host system.
Dutch researchers Ben Gras, Kaveh Razavi, Erik Bosman, Herbert Bos, and Cristiano Giuffrida of Vrije Universiteit (VU) in Amsterdam have come up with clever JavaScript that, while running silently on a webpage, can observe the processor’s memory management unit (MMU) in operation by measuring precise timings between memory accesses, work out where key data and code is mapped in memory, and render ASLR protections ineffective.
The MMU – present in desktop, mobile and server chips – is programmed by the operating system kernel to control where objects in virtual memory are held in physical memory. The time it takes for the unit to look up a physical address from a virtual memory access can be used, when performed over and over, to gradually leak the location of components.
The team has been able to write a proof-of-concept demonstration of the security weakness entirely in JS, and they say the code works on multiple architectures – including Intel and AMD x86 chips, and ARM-compatible cores.
“The memory management unit of modern processors uses the cache hierarchy of the processor in order to improve the performance of page table walks. This is fundamental to efficient code execution in modern processors,” the team explained today.
“Unfortunately, this cache hierarchy is also shared by untrusted applications, such as JavaScript code running in the browser.”
This, the VU team says, is what makes this vulnerability so significant. An attacker could embed the malicious JavaScript code in a webpage, and then run the assault without any user notification or interaction.
Because the assault does not rely on any special access or application flaws, it works on most browsers and operating systems. The researchers say that when tested on up-to-date web browsers, the exploit could fully unravel ASLR protections on 64-bit machines in about 90 seconds.
Infecting a system does not end there, of course: it just means ASLR has been defeated. The next step is to use this memory location information to launch a viable and reliable attack on bugs within the browser. Without this location information, the follow-up exploit would be fumbling in the dark. With the information, it’s easier to fully exploit the browser bugs. Below is a video of the JS code working in Firefox on a 64-bit Linux machine.
The researchers conclude that developers should not rely on ASLR as a strong security protection, and they should implement other measures to harden their browsers against exploits. Apple has already done just that, and acknowledged the VU researchers in its latest WebKit update – see the final note on that page.
For normal folk, the VU team suggests the best defense for now is to block untrusted JavaScript from executing with the use of a browser plugin such as NoScript. Future editions of browsers could come with builtin measures to potentially thwart MMU timing attacks.
Fully eliminating the vulnerability, however, will be difficult, and the group suggests effective protections may not be feasible until next-generation processors feature hardware mechanisms to defeat MMU side-channel snooping. The vulnerability is similar to the jump-over-ASLR technique we reported on in October.
We asked the Amsterdam team if their MMU timing vulnerability, dubbed AnC, is, honestly, practical to exploit. A lot of these types of flaws can be leveraged easily in a research lab, where conditions are quiet, controlled and ideal for attackers.
However, in the real world, computer systems are far more noisy, with CPU cores accessing all kinds of patterns of data, and processes being switched in and out of context as the user does their thing. That randomness tends to mess up timing-based attacks by introducing unexpectedly large latencies.
“There is no doubt that this side channel attack works and is practical on everyday browsers,” Gras told The Register. He continued:
Most previous work on side-channel attacks assumes that the attacker is running in a different process or virtual machine but on the same machine. Further, they usually attack cryptographic operations, something that the average Internet user does not usually do. The difference with AnC is that it runs from JavaScript and targets something that every Internet user relies on for security, namely ASLR.
The attack is also quite practical: it runs on any architecture that we tried and can quickly break 27 bits of entropy within a few seconds. As a reference, Microsoft Windows only provides 24 bits of entropy for its heap.
The prototype implementation was implemented it on normal browsers on normal Linuxes. The video on the AnC projects page visualizing the attack in Firefox is real and not cherry-picked. Just for completeness sake however, this does not mean the prototype is ready to be deployed as an in-the-wild attack – our goal is to prove that it is possible to use this work in a realistic attack, not to actually do it. The Chrome version relies on a feature that is still being standardized and not enabled by default (Javascript Shared memory), but is on schedule to be in the future. Also, the scope of this work is that we are breaking ASLR and therefore an additional memory corruption bug is needed to complete an exploit chain. This greatly reduces the burden on the attacker however, who would normally need another bug to leak ASLR information.
Source:https://www.theregister.co.uk
Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.
