Slashdot Mirror
JavaScript Attack Breaks ASLR On 22 CPU Architectures (bleepingcomputer.com)
An anonymous reader quotes a report from BleepingComputer: Five researchers from the Vrije University in the Netherlands have put together an attack that can be carried out via JavaScript code and break ASLR protection on at least 22 microprocessor architectures from vendors such as Intel, AMD, ARM, Allwinner, Nvidia, and others. The attack, christened ASLRCache, or AnC, focuses on the memory management unit (MMU), a lesser known component of many CPU architectures, which is tasked with improving performance for cache management operations. What researchers discovered was that this component shares some of its cache with untrusted applications, including browsers. This meant that researchers could send malicious JavaScript that specifically targeted this shared memory space and attempted to read its content. In layman's terms, this means an AnC attack can break ASLR and allow the attacker to read portions of the computer's memory, which he could then use to launch more complex exploits and escalate access to the entire OS. Researchers have published two papers [1, 2] detailing the AnC attack, along with two videos[1, 2] showing the attack in action.
It's been every few days since javascript even came onto the scene that we have seen some exploit using javascript as an attack vector.
It is a fundamentally flawed idea to run javascript that any random site happens to deliver to you. The number of ways that can go badly seems to be effectively endless.
If you care at all about the security of your machine, you should not be running javascript by default. This is where a bunch of people come out of the woodwork to say "but we need it to view $RANDOMSITE!". First, you need it because you have trained web developers that it is OK to depend on it. Second, if it has legit uses once in a while, then whitelist those, rather than allowing any random site.
Or, live with the endless series of exploits. Your call.
'cause every layman knows what ASLR is.
I had the same thought. At first I thought it was related to digital photography. Here is what this is really all about: https://en.wikipedia.org/wiki/Address_space_layout_randomization
In layman's terms: Keeping the locations of things in memory unpredictable so that, for example, if I am trying to exploit some arbitrary code execution flaw I can't count that my code will end up in the place I want or expect it.
Multi-CPU motherboards existed before multi-core CPUs. Kids these days...
Personally, I would run my frying pan on a computer with 22 CPUs.
It doesn't try to, it's a side-channel attack. So, ASLR pads elements with a random amount of free space, so a hacker doesn't know where to jump to. This attack figures out how big the free space is, by figuring out where the end of a cache line is. It figures out where the end of a cache line is by looking at the memory access times. So:
//runs in .5microseconds //runs in 10 microseconds
x = a[n];
x = a[n+1];
You know you hit a cache miss on the second access, and the end of a cache line is right between a[n] and a[n+1]. Based on the offset from where the cache would normally be, you can figure out how big the ASLR padding is. Once you know the padding size, you can know exactly which address to jump to to when you inject your shell code (ie, your compiled assembly exploit).
There are other ways to defeat ASLR too, so I am not sure how useful this is, but the more techniques a hacker has, the better (from his perspective).
"First they came for the slanderers and i said nothing."
This new Java script attack does *NOT* by itself compromise data, but simply allow a way to remotely extract the Address Space Layout Randomization that is currently employed by the OS. It does this by employing a javascript timer to measure page table walk times which are induced by executing javascript that accesses carefully selected offset in large objects (an earlier attempt to do this was frustrated by javascript implementations deliberately sabotaging the built-in high precision timer object). Once the specific ASLR pattern is determined for this specific boot of the kernel, other kernel vulnerabilities that involved direct access to aliased cache and/or memory locations that were mitigated by the kernel doing ASLR can now be modified to target the desired addresses on the target.
It's like knowing how to make key to break into a specific car, but if you use it on the wrong car, it triggers the car alarm and not knowing what car the key it works on. If you magically had a way to map the VIN to the car key, you could make a key that works for that car and steal the car. The car dealers have this mapping, so they can make a key for you, but what someone came up with a way to figure out the VIN->KEY mapping over the internet?