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.
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.
Somebody can tell me how I can block this attack with a HOSTS file?
who would run anything on a machine with 22 CPUs? That's just ASKING to have your ASLR broken, right?
So how exactly does this hurt me if the VM sandbox is secure? The paper seems to imply that you need other, much worse vulnerabilities to begin with to make use of this (beyond extracting information).
Ezekiel 23:20
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.
When was it broken and who is breaking it in the wild?
Security services? Federal law enforcement with lots of funding? Government workers? Private sector? Groups of very smart people?
People with skills and a few powerful computers? People reusing code created by people with skills and one home computer?
Any news on ip ranges and time zones?
Domestic spying is now "Benign Information Gathering"
I do think things like Skylake and K10 are different microarchs, even if using the same or almost identical IA. Otherwise, you're getting close to saying the P5 and P6 were the same microarchs.
Slashdot: Playing Favorites Since 1997
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.
Whaaaa....??
It little behooves the best of us to comment on the rest of us.
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?
this component shares some of its cache with untrusted applications, including browsers
Why does the MMU need to give user space apps access to its cache? Isn't the O/S, firmware and microcode supposed to provide a logical view of hardware like memory to prevent this sort of abuse?
Have gnu, will travel.
Where I work we make security and authentication tools. Half the western world uses our products to authenticate themselves. Our products shouldn't use javascript. I would prefer that everyone in the world browse the internet with javascript turned off by default. If you go to a site you trust then turn it on. Unfortunately my own company forces people to use javascript because it makes sites look shiny and modern and pages are more responsive.(assuming you load 4MB of javascript bloat to a simple login page)
What do you mean? A binary or grey code 11?
#DeleteFacebook
1011
If the MMU is lesser known to you, then the ALU is going to blow your mind. Just don't look at MMX, it's ugly.
"First they came for the slanderers and i said nothing."
It may draw the ire of those who feel that he was overspecific to indentify javascript. Scripting and maybe more specifically scripting from untrustworthy sources is the problem, and I don't know where, for example, going from HTML to HTML + CSS, to full blown scripting the problem occurs.
That's sort of inaccurate as well, scripting itself is overspecific for executable code in general.
ARM and x86 are instruction sets not architectures.
>, which is tasked with improving performance for cache management operations.
Stopped reading right there. These guys have no idea what they're talking about.
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.)
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?
Could you summarise?
So the MMU is a lesser known part of the CPU these days? *sigh*
On a long enough timeline, the survival rate for everyone drops to zero.
Google uses a v8 apparently: https://en.wikipedia.org/wiki/...
Dude, at the end of the day, unless you've written ever bit of code your computer is running yourself, you'll be running code you can't trust 100%.
Whether it's some shitty JavaScript in the browser or some shitty telemetry gathering shit in the shitty OS, you might well be boned.
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.
In other words, we've created CPUs with instruction set architectures so sophisticated that they can't be made safe from exploitation.
I may not understand the solution (if there is one), but I certainly admire the problem.
Just cruising through this digital world at 33 1/3 rpm...
Only terrorists need javascript. We must ban it to prevent it from sapping and impurifying all of our precious bodily fluids.
(My apologies to General Jack D. Ripper)
Just cruising through this digital world at 33 1/3 rpm...
That's because Google is an American company.
Baidu on the other hand, uses a 4-cylinder Boxer search engine.
And Bing uses that pathetic GMC 3-cylinder they used in the Hummer H3.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
"Javascript Attack Breaks ASMR on 22 CPU Architectures"
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
No, the appropriate response would be to justify the belief that ARM and x86 are architectures and not merely instruction sets that architectures like Kaby Lake and Coppermine implement.
Point to me a decent web site that could be developed without JavaScript. Please do.
It depends on how lenient you are about accepting examples that depend on nonexistent standards. If standards were created that implemented functions that were only good for exactly one task instead of a general purpose language, the web would be much more secure.
Don't run code you don't trust.
Not possible on a modern computer. But thanks for the advice.
The problem is that it's designed to be insecure because it's based solely on the advertising model. Somehow the old AOL subscription model is not seeming so bad these days.