ANC - The Ultimate Vulnerability that just killed Javascript entirely

Hardware CPU
1

Address Space Layout Randomisation (ASLR)

The term probably doesn't ring a bell, but it's the principle all modern CPU's use to streamline performance, and it's even considered a security feature. It's actually a hardware feature, basically the CPU contains a cache memory that holds the memory page table, and the random attribution of memory blocks to processes is stored there.

Now imagine that there is a system that allows a very simple unsuspected script to "ping" that hardware cache and thus, by pinging different regions one by one at random, can derandomize and reverse engineer the memory allocation table and it's usage by applications. That means that the memory space occupied by running applications, even system applications that are protected by the strongest software protection mechanisms like role-based access control systems, can be profiled, and this information can then be used to gain privileges or to take control over processes or to steal data, etc...

Well, this script is called AnC, short for "ASLR and Cache", and is a basically very simple javascript based attack developed by the VUSec group of the Vrije Universiteit Amsterdam in the Netherlands.

It basically means that - whatever operating system and security measures you're rocking - you're a sitting duck as long as you allow javascript on your machine, at least as long as you allow javacsript execution that is not your own.

This means that every ad, every webpage with javascript, every app or even GUI front, even that webbased control page of your router or your RGB lighting, is a direct and highly dangerous attack vector.

The only thing you can do is avoid all javascript execution ever.

And the coolest thing is: there is absolutely nothing that can be done against it, because every single modern CPU has this exact vulnerability, it's a hardware vulnerability even many times worse than the two main Intel hardware vulnerabilities (cross-core bleed and NSA-style RNG's) that have already caused so much problems, and that won't ever be fixed by Intel because the powers that be and greed and other things.

So this either instantly kills javascript entirely overnight, or it causes the short term end of the world as we know it.

The full information and demonstration can be found on the VUSec site at: https://www.vusec.net/projects/anc/

My recommendation: immediately activate NoScript or similar in all browsers, stop using Android, block all ads, and wait for the development of the next generation of CPU's that has a hardware fix, which shouldn't take more than five years or so lol...

Thoughts?

16 Likes
2

What about power9? Also why stop using android?

Make me wonder, was RMS right again?

Anyway, it seems this is proof of concept on accessing memory its not supposed to to employ further attacks?

Jevascript has never been much of a trustworthy or secure technology, this is just another example of that. Though it looks like a number of things have to line up for this to be an exploitable vulnerability. Maybe new hardware can be made before someone finds a way to exploit this in the wild.

2 Likes
3

Power9 also, it uses address space randomisation and execute disable bit like every other advanced CPU. There is no alternative to ASLR, and there is no cure against the ASLR vulnerability because it's structural. The only real solution could come from open source hardware designs allowing for individualized user-defined encryption to hardware level I guess lol. Hell will freeze over before the big bakers will allow that to happen. MCU's are safe though, so you can still use a calculator...

Android is - in unrooted default form - a breeding ground of all kinds of javascript injections, especially ads. Google has been integrating a lot of javascript based stuff deep into the system, so that users can't disable it. It should be super easy to have Google inject your unassuming javascript vector package through it's own ad system and enhanced content system. It's well documented that Google doesn't check anything unless there are actual complaints. Android is the new wild wild west.

You don't need extra attacks, when you can reverse engineer the processes, because it will give you the necessary data to directly take over root processes, because you know exactly what you have to do, it gives you basically the heart of the system, behind all of the security locks and firewalls, if you have the address table, you're superroot already.

Edit: Oh and the OEM's were advised more than 3 months beforehand, and nobody, literally nobody, reacted. And even online banking or webmail: the authentication mechanisms use javascript, anything except basic "library style" web browsing is fatally dangerous right now as a consequence of this hardware bug. And an extra software security layer would be futile, it would have to really analyse every single javascript process for behaviour, and that would completely kill CPU performance to pretty much 80286 level. And killing javascript entirely is also nothing more than a temporary patch, because if it works with javascript, how long will it take for hackers to figure out how to get it working elsewhere. This is literally the Achilles' heel of all current CPU designs, and there is no solution except a completely new design that allows users to define a unique encryption right into the cache memory of their hardware, and the powers that be will never ever let that happen.

It also means that pretty much every connected CPU based piece of hardware can be compromised, regardless of operating system. This can pretty much kill entire modern weapon arsenals in a matter of weeks. The big corporations will minimize the problem and will try to mitigate it in their classic way, while reality catches up with them, but this is a deluge class global event, it could pretty much mean that everyone goes back to the 1980's technologically. Imagine the ban on modern x86 computer hardware working in favour of North-Korea? Imagine every modern nuclear arsenal disabled and the only one that still works is the North-Korean? It is not completely unthinkable unless it is addressed properly, and addressing it will probably mean the death of many technology giants and technology companies and a complete overturning of the world economy.

1 Like
4

We almost covered this for the news but there are some aspects of this that are developing still. One wonders if this flaw in the algorithm was introduced

6 Likes
5

First off, WOW...

  1. If randomization was supposed to be a security feature, does that mean that older processors without this feature were insecure by default all this time?

  2. If not, what "older" generations are safe from this?

  3. Could this be applicable through something other than javascript? What makes javascript special, there are other vectors that are equally widespread? edit: okay, you've already covered this one in your edit...

6

By extra attacks I mean you still have to get the code to run either by breaking the browser or site sending the code. Then using it to exploit the memory your trying to access which may or may not be there.

Not that it makes it any less of a vulnerability.

Open verifiable "don't run if not signed" code would be nice at least and may offer some protection even if it's minor and as broken an idea as SSL.

7

If you read the VUSec paper, it's not very probable that it was introduced, but more plausible that technology just caught up with a fundamental oversight. The reality is that encryption technology is the only technology that can shield against things like this, actual mathematical randomisation to the nth degree that is put solely under control of the end user. Imagine the scenario where you have to go to a shop to buy a chip, and then have to enter actual complex entropy for yourself, by for instance physically interacting with a matrix, and then that blows fuses on your unique chip that freezes this entropy for on-chip encryption purposes. It would boost open source hardware designs, but would also mean that the price of an i3-class CPU would be close to a 1000 bucks. It's the only real solution though, but it would also exclude any government or industry sponsored outfit to spike the hardware in a conclusive way, and people would not pay so much money unless they would have total guarantee that it isn't spiked, so they would go for open source designs from companies in independent countries and independent bakers, basically practically limiting the chips to around 45nm lithography because that's about the best anyone can bake on a small machine in the back of a retail style shop. It would also create a new interest of hackers to actually bake their own chips, which would probably unleash a new wave of extreme law enforcement and arbitrary suppression, the like of which have been unseen since the German US-infiltrated "agencies" "dealt" with the original Chaos Computer Club founders (the most well known incident is the one where one of the founders first committed suicide in his car and then got out and lit his car on fire...).

8

As you say, there is no guarantee in the digital signatures, first of all they are a complete joke because every hacker and their dog has a big reserve stock of Microsoft certificates, lol, because that's a thing, and then there are all of the "sponsored" certification authorities...

Google doesn't check code, they check everything with malware scanners, but this isn't malware, the only thing it does is execute actual functional harmless code in intervals, then use the own process of the own program to ping the MAT, and map that in order to derandomize the cached allocation table. There is absolutely no "extraordinary" process going on, it's basically just metadata harvesting supercharged. You can just pay Google to plug an ad, and then that ad gives you absolute control over everything lol

9

Isn't there already a thread on this?

3 Likes
10

  1. basically, yes, ASLR and execute disable bit were implemented to prevent easy memory mapping

  2. basically, pretty much only MCU's, devices whereby software processes can allocate memory space are all vulnerable. MCU's have a fixed memory structure, and are not application processors, they have a very reduced instruction set. So you can still use and AVR Arduino or a calculator lol

1 Like
11

Missed that thread, sorry.

I won't merge them though because the other thread limits it to 22 types and gets off on the wrong foot as to the actual impact in my opinion. This merrits a restart of the discussion in itself in my opinion.

12

We could observe the MMU signal in the following 22 microarchitectures from Intel, ARM and AMD processors.

Okay and the list has tested CPUs, but there is also this sentence attached.

There was no architecture that we tried without observing the MMU signal.

So that means literally all of them right. I am guessing it is a problem on one of the family it is on all of them. So the 8120 listed means every bulldozer CPU made.

13

Yeah, in reality it's every single CPU that implements ASLR, which has been around for a really long time. And CPU's older than that are sitting ducks in terms of memory allocation table mapping anyway, so certainly not more secure.

1 Like
14

Another tidbit from another article.

The Chrome version relies on a feature that is still being standardized and not enabled by default (Javascript Shared memory), but is on schedule to be in the future.

So right now this does not work on chrome and with any luck it will never get that feature now.

15

the fact that it has been found is a major surprise. i have had a sneaking suspicion that there has been a major flaw in almost every processor made in the past 15 years. and the fact that it is java is no big surprise either, have not liked it since sun was bought by oracle. will be interesting to see how this changes things for zen 2.0 and skull canyon. and yes users able to tweak there micro code would be nice as a result but i highly doubt it will ever happen.

1 Like
16

Was RMS ever wrong?

Stallman 1.jpg3872x2592 861 KB
5 Likes
17

Well that's just lovely. Reason number 9001 why we're fucked. Great. Lol rip us.

18

Time to short ORCL?

Edit: After some research Oracle makes most of its money from its applications and other services, I don't know how many of those application or services are JavaScript dependent, looking into it. But I wonder what other companies are very Javascript dependent?

19

Java and JavaScript are not the same thing...

1 Like
20

I'm not into programming and whatnot so most of this thread is going right over my head, but I do find it kind of ironic discussing Javascript exploits on a forum that uses Javascript.