Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 17 submissions in the queue.
posted by on Thursday February 16 2017, @07:52AM   Printer-friendly
from the more-secure-every-day dept.

Submitted via IRC for TheMightyBuzzard

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."

This knowledge allows attackers to successfully execute malicious payloads on the targeted system, instead of crashing it.

Ruh-Roh, Raggy...

Source: https://www.helpnetsecurity.com/2017/02/15/bypass-aslr-protection-javascript/.
Also at: https://arstechnica.com/security/2017/02/new-aslr-busting-javascript-is-about-to-make-drive-by-exploits-much-nastier/.


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by Nerdfest on Thursday February 16 2017, @01:07PM

    by Nerdfest (80) on Thursday February 16 2017, @01:07PM (#467770)

    Is there any way this can be stopped? Basically, it sounds like the processor is missing some features that would be required to do it properly.

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

      by tibman (134) Subscriber Badge on Thursday February 16 2017, @02:46PM (#467798)

      It's a hardware issue : (

      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.

      --
      SN won't survive on lurkers alone. Write comments.
      • (Score: 2) by Nerdfest on Thursday February 16 2017, @03:57PM

        by Nerdfest (80) on Thursday February 16 2017, @03:57PM (#467835)

        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).

        • (Score: 2) by Scruffy Beard 2 on Friday February 17 2017, @02:09AM

          by Scruffy Beard 2 (6030) on Friday February 17 2017, @02:09AM (#468043)

          I recently discovered leaving the wrong website open drains you battery.

          Not sure why idle pages should be drawing any CPU time.

          In this case it was probably polling for updates I don't care about because, well: I was not looking at the page, and had disabled networking to save power.

  • (Score: 3, Interesting) by digitalaudiorock on Thursday February 16 2017, @03:17PM

    by digitalaudiorock (688) on Thursday February 16 2017, @03:17PM (#467815) Journal

    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.

    • (Score: 2) by Celestial on Thursday February 16 2017, @04:27PM

      by Celestial (4891) on Thursday February 16 2017, @04:27PM (#467852) Journal

      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.

    • (Score: 4, Interesting) by Anonymous Coward on Thursday February 16 2017, @04:29PM

      by Anonymous Coward on Thursday February 16 2017, @04:29PM (#467853)

      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.

      • (Score: 1) by lcall on Thursday February 16 2017, @04:46PM

        by lcall (4611) on Thursday February 16 2017, @04:46PM (#467860)

        Compliments to AC on how you put that.

        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.

        --
        A Free, fast, flexible personal organizer for touch typists: http://onemodel.org [onemodel.org]