A group of researchers from the Systems and Network Security Group at VU Amsterdam have discovered a way to bypass address space layout randomization (ASLR) protections of major operating systems and browsers by exploiting a common feature of computer microprocessors.

By combining simple JavaScript code to target this feature with exploit code for browser or OS vulnerabilities, they were able to compromise vulnerable systems, as demonstrated in this video (on Linux and Firefox):

"The memory management unit (MMU) of modern processors uses the cache hierarchy of the processor in order to improve the performance of page table walks. Unfortunately, this cache hierarchy is also shared by untrustred applications, such as JavaScript code running in the browser," the researchers explained.

"Our attack relies on the interplay between the MMU and the caches during virtual to physical address translation—core hardware behavior that is central to efficient code execution on modern CPUs. We have built a side-channel attack, specifically an EVICT+TIME cache attack, that can detect which locations in the page table pages are accessed during a page table walk performed by the MMU. As a result, an attacker can derandomize virtual addresses of a victim's code and data by locating the cache lines that store the page-table entries used for address translation."

Re:BummerRe:Bummer(Score: 2) by tibman on Thursday February 16 2017, @02:46PM

How can I protect myself as a user against the AnC attack?You unfortunately cannot as AnC exploits the fundamental properties of your processor. You can however stop untrusted JavaScript code from being executed on your browser using a plugin such as NoScript [noscript.net].

The attack was effective against every processor they tried (after some tweaking). There is a processor list around 2/3rds down the page. Would have linked it but they have no linkable elements.

Re:BummerRe:Bummer(Score: 2) by Nerdfest on Thursday February 16 2017, @03:57PM

Thanks. I do Javascript whitelisting, and recently even started doing it on FireFox for Android. Running extra scripts of a mobile platform just seems dangerous, and silly (for bandwidth and processor).

Still using NoScriptStill using NoScript(Score: 3, Interesting) by digitalaudiorock on Thursday February 16 2017, @03:17PM

I still use NoScript in spite of the fact that it makes the current sorry excuse for a world Wide Web all but unusable. Some people I know who were using NoScript finally gave up. This sort of thing makes me glad I still do.

It really is a grim scene out there though, even on high profile sites that you would expect to be "reputable" they want to drag in JS from 25 sites. Even if they were vetting all those sites, each of those site's JS is dragging in more JS from other sites, and so on, sometimes to several levels. You can end up with code pulled into your browser from 50 or more sites. This is why some sites don't fully "work" as intended unless you tell NoScript to "temporarily allow all on this page" as many as three times. How fucking crazy is that?...yet almost all of the general public has no idea this is even happening, and it's getting where everything on the web is like that. Just plain sad.

Re:Still using NoScript(Score: 2) by Celestial on Thursday February 16 2017, @04:27PM

I stopped using NoScript around 2013. The modern world wide web is almost completely broken by it as the use of JavaScript has become nearly 100% ubiquitous now. I just have to hope that uBlock Origin, Disconnect, and Privacy Badger are good enough.

Re:Still using NoScriptRe:Still using NoScript(Score: 4, Interesting) by Anonymous Coward on Thursday February 16 2017, @04:29PM

As someone who works for a company that produces a javascript heavy site, I will add that internally it's just as frustrating. It's the same old story heard over and over again. Features that can be done quickly are prioritized over features that take more time. Implementing in JavaScript using third party libraries and functions can be done very quickly by a small number of web-devs. Doing it right, with only the minimum of JavaScript and little/no third party libraries and functions, takes much longer and requires much more skilled developers. And there are many times when developers aren't wanted at all. For example, it's easier to include a third party library on your page that allows content filtering/changes so a product person can do a series of A/B tests, than to implement true A/B functionality across the website.

Time to market. I see no solution to the craziness out there as long as time to market dominates development decisions. And it goes all the way up to the CEO in my company - all of us who point out the logic problems are asked to "think bigger". We are, trust us, we are.

Re:Still using NoScript(Score: 1) by lcall on Thursday February 16 2017, @04:46PM

I just try, when possible, to not need or use sites, that require javascript. Most of what I want is text anyway or I try to find it elsewhere. I've got the habit of leaving a tab open to turn javascript on for those rare occasions I really need something on a site I don't already trust enough to make it a permanent exception. Same with images. Same with the long site agreements: I hate reading them or agreeing to something I don't know whether I will really keep my end of it, or if it the terms are acceptable to me. So I try to find a way not to use the site. Not that I'm making a difference that I can see, but maybe if I some of us do and say it enough. And I feel more peaceful that way anyway. :)

It's like with people, trust is earned. And even on the web there is a certain element of deciding what to trust and what to not bother with.