Paper: vusec.net
From page1
Page 6
>[26]: asmjs.org
tl;dr
Another JIT spray from the browser fucks your shitty kernel security
WHY. why assembly javascript? we saw the bad news coming down the tracks years ago, Holla Forums.
hope the greentext works.
Other urls found in this thread:
elinks.or.cz
destroyallsoftware.com
archive.fo
twitter.com
I just got done writing a short article on the information provided by VUSec on their website for my security class. According to the information I parsed, this a hardware level problem with the MMU which affects certain architectures. The only fix is for the stupid fucks that maintain Chrome, firefox, or any other of your favorite shitty pozzed up web browser to implement minor software changes and they can't even guarantee that someone else will find another method of bypassing the implementations. Pajeet really fucked us on this one.
Jesus H. Christ! This is what a call a grade A fucking mess!
Do you know enough about grsec's patches to tell whether this attack would derandomize their version of ASLR? Or if it is independent of ASLR implementation?
Because these idiots don't learn. I don't mean that metaphorically and I am not exaggerating. If an animal gets hurt by a stupid action often enough, it ceases that action. The retards that currently run most of the technology field don't do that. Every time, it's the same script:
>woooow bugged sawing mechanics, nobody could have predicted this
Rinse, repeat. This field makes you want to kill yourself.
I have no idea at the moment since this has just popped in the last day or so, but I'll have to look more into it. However, I suspect that this vulnerablility also may affect grsec's version of ASLR since AnC (VUSec's name for the exploitation) relies upon certain CPUs that have MMUs that allow this attack to be executed from. There's a list that contains the architectures and CPU models that are affected by AnC in the link in your original post. Hopefully they won't be adding anymore, but for now any modern processor could theoretically be vulnerable to exploitations/attacks that are similar in nature to that of AnC. I'll post any more information I find since I'm intrigued by this in a sort of morbid way.
Disable Javascript, problem solved.
This is a pretty ugly attack. Derandomizing the addresses permits directly targeted attacks or worst case a concentrated spray over much fewer potential locations but the paper said somewhere around 150 seconds for it to execute.
So this and this
prove one thing.
We Must Kill Javascript
How should we accomplish that?
We can boycott it all we want, as says. I disagree that the problem is solved by non-participation alone.
Webdevs will still make libraries and code for normalshit websites whose audience/users give no fucks about things like this. As long as those users make money for the websites, the code will continue to be used.
"Solved" might have been too grand a word but at least it would be avoided. I wonder if the attack would work from inside a VM, could distance it from the hardware enough to not be effective?
Replace it with a better language and framework. Python/Django perhaps? At this point everything is so fucked up beyond repair that playing around and testing different solutions, or coming up with something that could fix this cluster fuck diarrhea bomb era in web development wouldn't hurt. All web developers care about these days is if their fucking site looks good enough when compared to another mainstream shitfest of a web interface owned by Facebook, etc. They throw all consideration for security and proper handling and parsing of user input to the wayside. In fact they don't even think about it until someone on the outside fucks with it and only then do they do something about it.
Not only that, but hardware is getting shittier too. Hardware manufacturers are so busy cramming their shit tier hardware with unwanted garbage and running up the prices that they don't even consider security at the hardware level either. The AnC exploitation and other variants similar to it utilizes flaws at the hardware level that's present in the manufacturing of CPUs of various architectures and brands which can't be fixed with a simple patch, because some engineer fubar'd the calculations during the design phase. Which means they'll have to make another line of new processors, which means you and I have to buy it if we want to be protected from attacks like AnC, thus puts more money in their pockets.
EVERYTHING IS SO FUCKED AND IM FUCKING SICK OF THESE FUCKS THAT KEEP FUCKING IT UP!
Replacing JS just moves the problem around a bit, but doesn't get rid of it. You'll still have vulnerabilities based on easy access to run arbitrary code on user's machine.
From my POV, it's better to avoid client-side scripting altogether. Unless we're talking about code that *you* wrote to automate shit in your browser, or maybe a plugin type thing that someone reputable wrote. That's still not as good as no scripting, but it's a lot safer than allowing servers to shove random code up your ass.
Anyway, I stick with Lynx and Links for hte most part. They surely have their own bugs (as with all software) but the attack surface is tiny compared to Firefox, Chrome, and such.
I don't like modern hardware at all though. Actually never liked Intel stuff to begin with. Last good computer I owned was Amiga, but anything 68k based like old Macs, Atari, Sun, and NeXT workstations was pretty sweet.
This autistic rage is almost as amusing to watch as the time grsec deleted their twitter account over the cat /dev/null > /dev/tty DoS
And is there a way to write it in something other than JavaScript?
Go-js and ClojureScript are better languages, but will still be running as JavaScript compiled code.
Also there is no an easy way to write a plugin or even a userscript in such language.
You could still alter html code by privoxy, using any custom script, which is nice and pretty safe.
Elinks lets you do some client scripting via Lua or Guile (Scheme).
elinks.or.cz
Yeh, super autistic to have a problem with untrusted code causing your browser engine to do repeated low level memory access. People should know that security is simply a joke, and have it thrown in their face constantly
page 4? slid much
people must know what kind of power webkit/gecko browsers give to javascript from the internet over their machines
all these crappy not-tech posts drown informational threads
This isn't a JavaScript problem, it can be abused from any software on the client.
They just used JavaScript to prove it could be used remotely.
Using a VM doesn't fix it, the problem lies in the fact that the page tables must be stored in the cache of the cpu for performance reasons.
Languages that run in a vm could be made to be unable to exploit this, IE: Java/C#, javascripts JIT means it's not really running in a vm and that's why it is able to exploit it.
Something interesting about Holla Forums is that any thread requiring actual technical knowledge doesn't get any interest. The only threads that get bumped are the ones where every other post is complaining about how this thread is killing tech.
I really wish I could find that speech where the guy rambles about asm.js as if it is a historical post-mortem.
No, you're just a fucking retard from Holla Forums
Tranny detected
That might be an interesting discussion
But this thread is about memory address derandomization with JIT spraying. We could hold it somewhere else.
Really? Tell me and above quoted user how many threads on Holla Forums are actually tech.
Do you probably mean The Birth and Death of Javascript?
destroyallsoftware.com
I think this is mostly because the majority of Holla Forums isn't technical beyond "I can install Linux and configure a ricer WM". Tech fanboys seem to make up the majority of the board and they only reply to what they can reply to: Shitpost threads about systemd, muh SJWs, why is my browser slow, Holla Forums meta, and OS wars. It would be really nice if these "people" fucked off and we had a nice comfy technology board, but that won't happen.
>Do you probably mean The Birth and Death of Javascript?
Always proofread your posts after an edit.
Bump
replace js
cuck
((upgrades))
One of the most important features added to Firefox 52 is support for WebAssembly, a low-level programming language that can make web apps run at near-native speed.
This will make WebAssembly especially more useful for browser games, advanced web apps, and software libraries. Mozilla has been one of the primary developers of the language, as it wanted to offer a standardized alternative to Google’s Native Client API, which boasts similar performance. The organization seems to have succeeded in that goal, as WebAssembly should soon be adopted by all the major browsers.
all major browsers, the botnet is here to stay