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
First off, WOW...
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?
If not, what "older" generations are safe from this?
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...
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.
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...).
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
Isn't there already a thread on this?
3 Likes
basically, yes, ASLR and execute disable bit were implemented to prevent easy memory mapping
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
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.
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.
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
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.
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
Well that's just lovely. Reason number 9001 why we're fucked. Great. Lol rip us.
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?
Java and JavaScript are not the same thing...
1 Like
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.
source of javascript on this forum is discourse though, open source software, you can actually know and check for yourself what javascript code is going to be executed before you actually visit the site.
What about environments that use a fully randomized VDSO and PIE base execution randomization? from my understanding this exploit relies on other points of determinism in ASLR implementation to utilize the exploit, so the less transparent the implementation, the fewer points of failure and thus lower attack surface area.
The testing indicated that the exploit assumes transparent interfacing.
[Looks at copyleft, GPL3, The Hurd, The Gnu Plus Linux Rant]
Yeah, about that...