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.
AllWinner does ARM (maybe MIPS), NVidia does ARM (don't think they do MIPS). There is a lot of x86_64. Same architecture: x86 64 bit (and maybe 32 bit), maybe different generations.
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.
I just had a meeting with these guys discussing this with these guys, and now I'm reading about it on slashdot.
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.
This is why computer architectures need a complete overhaul. Pick up a copy of "Inside The AS/400" for a better understanding of what security could be like.
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"
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)
68xxx rulzes!!!!
I don't understand. The researchers said browsers have fuzzed their Javascript timer to block cache timing attacks so they had to make their own timer. So for their attack to be successful you need a browser with a customized Javascript engine? Why is the attack a big deal, no one is running a browser like that. Or did they somehow make a better timer purely out of Javascript? They aren't clear in this regard, but I'd expect vendors wouldn't be so interested in this attack unless they had made a new, portable timer. I'm so confused and it seem so far no one has noticed this despite their timer disclaimer being colored red in their article...
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.
Hosts do so in 1 step blocking scriptsource (ads/trackers offsite) before NoScript inefficiently parses tags! APK Hosts File Engine 9.0++ SR-7 32/64-bit https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22APK+Hosts+File+Engine%22+and+%22start64%22&btnG=Google+Search&gbv=1/
Hosts add speed (via hardcodes/adblocks), security (vs. bad sites/malware/poisoned dns), reliability (vs. dns down), & anonymity (vs. dns requestlogs/trackers).
Ads/malware rob speed/security/privacy
Less power/cpu/ram + IO vs. DNS/routers/addons/antivirus + less security bugs/complexity & faster vs. addons/routers/remote dns!
* Via what you NATIVELY have built in the IP stack in FASTER kernelmode!
APK
P.S. - Safe https://www.virustotal.com/en/file/e01211ca36aa02e923f20adee0a3c4f5d5187dc65bdf1c997b3da3c2b0745425/analysis/1433430542/ & virusproof HyperAlloy Combat Chassis - Microprocessor controlled: Fully Armored, VERY tough code construction... apk
There is a better link here:https://www.vusec.net/projects/anc/
>, which is tasked with improving performance for cache management operations.
Stopped reading right there. These guys have no idea what they're talking about.
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.)
No, they have run on 22 different implementations of 2 architectures. Maybe up to 4 if there are 32 and 64 bit variants of both x86 and ARM. But ASLR on 32 bit is ineffective because you have too few bits to play with, although the interactions between TLB misses and cache are probably harder to measure because the page make fewer accesses (2 or 3 versus 4 or 5, much more in virtual machines).
On the other hand, hashed page tables have very poor locality of reference, I believe that the ideal MMU should use a tree for the last 2 levels of page walk and a sideband hash table for the most significant address bits. The hash table could be kept small, and have more consistent performance behavior on page table look-ups. The other advantage of hashed page tables is that, when done right, they implicitly provide a per memory space identifier.
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?
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.
Wonder if antivirus has anything to do with it...
http://robert.ocallahan.org/2017/01/disable-your-antivirus-software-except.html
For example, back when we first made sure ASLR was working for Firefox on Windows, many AV vendors broke it by injecting their own ASLR-disabled DLLs into our processes. Several times AV software blocked Firefox updates, making it impossible for users to receive important security fixes.
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...
There are some shitty users connected to the shitty internet without knowing what they are doing in the first place. And that's how the problem gets started.
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.
You managed to pick the chief language that doesn't run on CPU's. JavaScript is interpreted; compilation to CPU instructions is not viable. The trick here is to get the script interpreter to expose ASLR details to the script. That's part of why it's so CPU-independent.
You should be able to run ANY high level language in a sandbox from within a browser with complete safety. If you cannot, then your language and/or browser is being coded by a chimpanzee who THINKS he's a young (millenial?) talented well-educated coder. Being able to produce junk is no sign of talent.
If you are not running machine code (which NO browser should allow), then you are running something interpreted by some other code (in this case a Javascript implementation) and probably hosted by some code (Explorer/Chrom/Firefox...) and NONE of this code should permit any high level code brought in via the browser to have ANY low-level access to the hardware or the underlying file system. To the extent that ANY code loaded into a browser via a web page is allowed to do ANYTHING even potentially dangerous or malicious on a machine, it's the exposure of complete programmer malpractice by bozos who are apparently more script-kiddie than serious programmer and who are spending more time adding new user interface features and new fad features than getting basic core functionality working. Probably this incompetence involves pasting together lots of piles of open source software and sticking it all together with the code equivalent of chewing gum, that stretchy fabric blood banks use to stop your arm leaking, and super glue.
I'm sorry to go on such a rant, but as a guy who works in the aerospace end of things where people are killed by ANY unsafe code ( work on "in-flight entertainment" idiocy) I have little patience for the over-payed morons of silicon valley who are always advertising their superior "innovation" and so-on while constructing systems so unsafe, brittle, insecure, and just plain crappy that they should not be entrusted to run a coffee machine. You are not an actual programmer if you are producing production code with bugs this bad, you are a foolish, undereducated, inexperienced, incompetent hack.
If you write code that can be hijacked and used for bad purposes, you should be banished from coding forever; please find a job in the lawn care profession or at a place wheree you cans spend your time asking "do you want fries with that" and stop screwing up the planet with your incompetence and giving MY profession a bad name.
Stupid buggy browser apparently screwed-up my posting (facepalm)
The parentheses SHOULD have said: (I do not work on "in-flight entertainment" idiocy)
It was right on my screen. I cannot believe how badly written/tested internet-related software is getting.
You are a worthless sack of shit. Advertise your crap where people might care about it.
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.
http://softwareengineeringmca....
One could argue that static HTML is also code. The only way to be safe is to block all outside data. Don't run anything that you haven't written and don't connect to any networks that you don't control all of the devices on. I recommend burning your computer and living in a cave. Blocking javascript is a slippery slope that leads to schizophrenia.