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.
In layman's terms, this means an AnC attack can break ASLR...
'cause every layman knows what ASLR is.
who would run anything on a machine with 22 CPUs? That's just ASKING to have your ASLR broken, right?
I thought Slashdot was supposed to be a tech site. What does Javascript attacks breaking ASLR on 22 microprocessor architectures have to do with tech?
You are welcome on my lawn.
OK, fair enough, but if it's expressed in another language (assuming it's not part of your OS) you have to explicitly get and run the malicious software. If it's javascript you get it just by visiting a web page with default browser settings.
Delivery is different, even if in theory you could get it via some other means.
No, semi-seriously.
The concept of a LISP machine was a computer which only executed one programming language, at least only one language in which non built-in code would execute.
And that language was memory secure, in that it packaged memory use into high-level cells which referenced each other in a single standard way.
There was no way that a process could "break out" and access something else's memory. A LISP program running in one process only understood and could access its own linked memory cells.
This was enough programming freedom to program whatever you wanted, and the point is, the memory model was simple, uniform, and thereby secure.
I'm not exactly saying return to LISP machines. I'm saying return to an architecture which includes a simple and secure memory access model, with no workarounds to the high-level memory cell access permitted. This could be enforced at the machine-language level, and/or by restricting allowed programming languages to inherently memory-secure ones.
Where are we going and why are we in a handbasket?
You're confusing CPU architecture with instruction set architecture. They used to be the same (and in some cases still are) but most processors have a physical architecture that implements an ISA via microcode translation. With memory controllers (and a whole lot of other shit) on the same package. the term "architecture" has drifted even further from ISA and more toward the entire SoC.
Don't run code you don't trust.
Javascript is code, no matter how much your browser tries to sandbox it or put shackles on it, it's going to be flying around in your CPU if you let it run.
If you don't trust the Javascript, don't run it.
There are 3 points to this problem:
Shitty fucking developers write shitty fucking websites that NEED Javascript to function.
Shitty fucking users like shiny, stupid shit and encourage that behavior.
Shitty fucking browsers let it all run by default and focus on speed, not security to please the shitty fucking users.
(And this loops back to shitty fucking developers seeing that they can bloat up their site even more because Chrome v8247 tweaked Javascript regex performance to be 2.8% faster.)
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?
You have got a car with Piers Morgan sitting in it. An attacker wants to head butt him in the face (trying to think of a backronym for AnC for this - I have Attacker Nuts... but I can't think of a word beginning with C that describes Piers Morgan) so, for his own protection, you choose where he sits in the car by a random process (Arsehole Seat Location Randomisation), so the chances are the attacker opens the wrong door.
Anyway, it turns out that you can tell by how the car is riding on its springs where Piers Morgan is.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
Yes, because every web page should be a static HTML document with zero interactivity. And web applications are a fad that will go away soon.