Changes in WebAssembly Could Render Meltdown and Spectre Browser Patches Useless (bleepingcomputer.com)

Catalin Cimpanu, reporting for BleepingComputer: Upcoming additions to the WebAssembly standard may render useless some of the mitigations put up at the browser level against Meltdown and Spectre attacks, according to John Bergbom, a security researcher at Forcepoint. WebAssembly (WA or Wasm) is a new technology that shipped last year and is currently supported within all major browsers, such as Chrome, Edge, Firefox, and Safari.

The technology is a compact binary language that a browser will convert into machine code and run it directly on the CPU. Browser makers created WebAssembly to improve the speed of delivery and performance of JavaScript code, but as a side effect, they also created a way for developers to port code from other high-level languages (such as C, C++, and others) into Wasm, and then run it inside a browser. All in all, the WebAssembly standard is viewed as a success in the web dev community, and there've been praises for it all around.

Comments

Who thought this was a good idea

[Anonymous Coward]

The fact so many webdevs see active x, but harder to control as a success just proves the entire node.js loving lot of them have no fucking clue what they are doing and shouldn't be allowed near a computer.

"Lets download and run executable automatically from the net! What could go wrong?"

Idiots.

Re:Who thought this was a good idea

[vtcodger]

Quit shilly shallying and let us know what you really think.

However, I completely agree with you. If we're going to let anybody on the planet download code to our computers then execute it, what's the point in worrying about Spectre and Meltdown? or passwords, or any other security measures for that matter?

It's been clear to me for decades -- ever since HTML email -- that the internet decision makers are more or less completely bonkers.

I do not expect the situation to end well.

Re: Who thought this was a good idea

[peppepz]

All of an user's valuable and sensitive information are accessible by its user account. Putting files into system32 is no longer the goal of hackers. And it is also less important now that the browsers have such a huge attack surface and are used as frequently as they are today; who needs persistence for malware when they can freely download machine code into a computer every time its owner opens a web page.

Re:Who thought this was a good idea

[LubosD]

You have no clue what wasm can and cannot do, right?

All wasm can do is to have a linear memory buffer for its memory allocations (kindly provided by JavaScript) and make some calls between wasm and JS. Wasm has absolutely no access to your system and any interaction with the outer world needs to be done via JS.

So quit whining.

Re:Who thought this was a good idea

[AmiMoJo]

WebAssembly makes sense when you think of the browser as the new OS. An OS that provides heavy sandboxing and a permission system.

Compiling to machine code may be a bit scary, but it's what all major browsers have been doing for a while now. JIT for Javascript was new a decade ago.

Running unverified code sounds crazy until you realize that that's what most people do most of the time. Even in the open source world few people bother to check the source or binaries they are getting from repos, and bad stuff has snuck in before. At least in the browser it's sandboxed.

I'm not saying I'll stop blocking JS or that this is necessarily all a good thing, but it's nothing like the bad old ActiveX days either.

Re:Who thought this was a good idea

[phantomfive]

"Lets download and run executable automatically from the net! What could go wrong?"

This is not any different than Javascript.

Who actually wants this?

[jittles]

Why would anyone want this? If a website isn't going to trust javascript content enough to host it on it's own site, I don't even want to let it execute. I definitely don't need faster javascript. I need less of it. Probably 90% of the javascript websites try to push on me are from 3rd party ad firms. I'd like to see some legislation that makes a website responsible for any 3rd party ad, script, or anything else it loads during normal execution. That would likely result in fewer ad networks pushing viruses around the internet since there would actually be someone to hold responsible for it.

Re:Who actually wants this?

[Anonymous Coward]

That would likely result in fewer of everything, everywhere. On the other hand, maybe making it 1994 on the Internet again wouldn't be such a bad thing with all the shit that's out there now.

Re:Who actually wants this?

[Anonymous Coward]

when sites pollute their code with dozens of ad and tracking scripts, it slows the site down, potentially losing impatient eyeballs.

which is precisely why google (who is an advertiser and data harvester first and foremost), et. al. pushed this abomination on us... so the bullshit scripts no end user wants doesn't kill browser performance... and maybe won't be noticed by the 95%+ of users without the knowledge or understanding to know what's really going on.

Re:Who actually wants this?

[phantomfive]

WebAssembly is a much safer interface than Javascript. The summary makes it sound like it's some kind of x86 code, but it's not. The fact that it is well thought out, and carefully designed to have a small attack surface means there is a smaller chance of finding exploits there.

So ideally, eventually all Javascript will be compiled to WebAssembly in the browser, and there will be no Javascript running on your machine at all.

Re:Who actually wants this?

[phantomfive]

I'm sure the systemd developers had those thoughts too when they started out. :-)

No, they didn't. You can see the documentation and ideas that were floating when systemd started. The concept is all about features, lots of them, and security is mainly mentioned as something the kernel will do. Minimalism isn't on the menu.

Contrast that with WebAssembly which takes years to add features that clearly need to be there (like access to the DOM), because they know it's better to do it right than half-assed.

Re:Who actually wants this?

[Bite The Pillow]

So we go from shit I can reformat and read, to shit I can't read? That's a hard no.

It's not about the attack surface. It's about knowing what runs.

I'll allow jQuery with a known hash, for example. But that means fewer websites work for me. I have money to spend, but I don't even click on certain websites that give me a blank page.

I'm guessing there are a lots of nerds who remember ActiveX and aren't willing to make that mistake. And also have excess cash inflow. But the decision makers don't remember a time when JavaScript was maybe not even an option. Graceful fallback. Yes some people still do that.

Re:Who actually wants this?

[tlhIngan]

WebAssembly is a much safer interface than Javascript. The summary makes it sound like it's some kind of x86 code, but it's not. The fact that it is well thought out, and carefully designed to have a small attack surface means there is a smaller chance of finding exploits there.

WebAssembly is an evolution of asm.js from Mozilla.It's actually JavaScript, but a small subset of it.

Asm.js came about as some Javascript engine writers for Mozilla were playing around (and ended up with a C to Javascript compiler) and discovered there were operations that the engine ran really fast. So asm.js was created to provide a turing-complete subset of Javascript that ran really fast in Mozilla.

I think the challenge was to run a game engine like Unity or Unreal in the browser without a plugin, which was why the C to Javascript compiler was created.

It became WebAssembly when Mozilla and other browser manufacturers got together to standardize the interface. It's not another language, but a controlled restricted subset of Javascript that ends up executing extremely quickly because they were simple and by restricting what Javascript you could use, the optimizers could make optimizations they could not in regular Javascript. End result is the Javascript JIT in the browser made fast and efficient code.

This also lead to the standardization of the C to WebAssembly compiler, which is why you now have even large projects like DOSBox compiled into WebAssembly, so you have the ability to run retro programs right in the browser (see the Internet Archive)..

It's likely what happened is the optimizations to WebAssembly bypass the mitigations - the restricted Javascript subset exists to be really fast and what happened is browser manufacturers may have forgot about the fast path.

Re:Who actually wants this?

[flink]

Webassembly is binary bytecode. It's something different.

What you describe is indeed asm.js, but that's not Webassembly.

But doesn't Javascript just get JIT'd down to binary bytecode these days anyway? And if that's the case, why not deliver the bytecode directly instead of having to perform the JIT step locally? As long as they are running in the same sandbox and the inputs get validated, there shouldn't be any difference between bytecode that your browser produces locally from source code and bytecode you load directly from an external source.

Re:Who actually wants this?

[phantomfive]

The difference between Javascript and Webassembly, is that the some of the features of the Javascript language make it slow, even if it's JIT'd down to bytecode.

TLDR; using thread loops to measure time.

[complete loony]

Since this detail was missing from the summary; Browsers have limited access to precise timers as a meltdown / spectre mitigation. Web assembly threads might give attackers a way to precisely measure time intervals by executing tight loops in another thread.

Not a big problem

[jonwil]

The WebAssembly guys are aware of this issue
https://github.com/WebAssembly...
and dont plan to actually support the new features until they have a solution.

Sigh...

[EmeraldBot]

1. WebAssembly is a compressed and simplified version of JavaScript. Anything you can do in WebAssembly, you can do in JavaScript. Seeing as Meltdown / Spectre take a lot of effort to exploit, if this attack is being deployed against you, it's reasonable to assume the attacker is perfectly willing to translate their code into JavaScript, which is already supported in your browser.
2. The devs are well aware of the issue and have said they're not going to reenable the feature that makes them vulnerable to timing attacks without making sure that the mitigations to Spectre / Meltdown are not going to be nullified by WebAssembly.

Re:Sigh...

[gweihir]

1. WebAssembly is a compressed and simplified version of JavaScript. Anything you can do in WebAssembly, you can do in JavaScript.

While theoretically true, it may not be in practice. For example, if taking the time precisely enough takes a few seconds in Web Assembly, but a few months in JavaScript, then one attack is valid and a threat, while the other is not in most circumstances. Efficiency does matter to security.

Re: Sigh...

[peppepz]

WebAssembly is not a compressed form of JavaScript. In fact, it has no relationship to JavaScript whatsoever. It allows site owners to run bytecode with the same memory semantics of C on their visitor's machine. As such, there is a lot of things that WebAssembly can do and were left out of the JavaScript design, such as smashing strings and overflowing buffers without the runtime noticing (because to it all the memory used by the script is just a giant array of bytes anyway).

Re:Hmm ...

[fahrbot-bot]

So... anyway to disable WebAssembly in FF? (Asking for a friend)

Answering my own question -- with, perhaps, some overkill ... (feel free to correct me)

// Disable WebAssembly
user_pref("devtools.debugger.features.wasm", false);
user_pref("javascript.options.wasm", false);
user_pref("javascript.options.wasm_baselinejit", false);
user_pref("javascript.options.wasm_ionjit", false);

Re:The Browser is now the desktop

[gweihir]

Not here, not before it runs fvwm on X on Linux.

Not a timing attack as claimed

[wllang]

Access to very accurate timers improves the efficiency of attacks but they are not the core of the attack and the attack still works with far less accurate timers. This has already been explained with proof of concept examples, see https://weblll.org/index.php/s... Attempts were made to have WebAssembly support mitigation techniques efficiently, but those in control appear to have had different plans and appear to be working towards using 32-bit indexing wasm in a large block of 64-bit address space to constrain attacks, but obviously that fails on 64-bit indexing wasm and is of no help in a 32-bit OS.

Re: The Browser is now the desktop

[K. S. Kyosuke]

Speculative execution has been a mainstay of both RISC and CISC cpu designs since the 80â(TM)s. Intel were one of the last CPU producers to implement speculative execution. IBM power chips, sun sparc chips, Motorola 16k chips, they all had speculative execution 10-20 years before intel introduced it in the pentium pro.

Seriously? RISC was supposed to be simple originally. It used to be pipelined, but speculated? Pentium Pro came out in 1995. You're claiming that POWER, SPARC and 68k had this in 1985 at the latest? Well, let's check the facts: SPARC was first released in 1987, POWER1 came out in 1990, in 1985, Motorola had the 68020. Only the 88110 introduced speculation in 1991

Stop. Lying.

No shit

[LostMyBeaver]

The JIT takes intermediate code and compiled it to native code. By making it that the JIT canâ€(TM)t generate the harmful code, the problem goes away. This is and always was the flaw with JavaScript. Exploits found in any engine that can allow code to be transmitted and executed on a foreign system has always been a security problem. The expertise in compiler development doesnâ€(TM)t always mirror the knowledge required to consider the exploit paths. Therefore, itâ€(TM)s unlikely all possible means of blocking these attacks will be found until they are first exploited. Even today, many of the best compiler developers can tell you absolutely everything a SPARC or a MIPS would do, but only a small number of engineers could explain the pipeline prior to speculative bytecode recompilation on x64 CPUs.

The engineers developing compiler optimizations for a JIT very likely does not always have the knowledge required to identify paths maliciPIs hackers might exploit the compiled code.

Code signing is a means of mitigating native code exploits. Of course, we all know people are not quite ready for things like Windows S. Though the Mac world embraces this environment.

Microsoftâ€(TM)s efforts to move almost entirely to managed code is a great step in the right direction. As RyuJIT gets even better, it will become the default for everything.

Finally, virtual machines. To handle these issues in that environment may sound impossible, but if you absolutely must run VMs which in theory would allow almost random strangers to provision their own insecure VMs to hack other users VMs, then realize that VMware and everyone else has implemented dynamic recompilers (JITs) for processing hardware emulation for a long time. VMware for example intercepts code targeting I/O operations that are based on legacy x86 I/O by recompiling the code as trapping I/O calls has never been supported. This is how legacy VMs are able to identify virtual hard drive parameters through sequential calls to inb against a virtualized CMOS chip.

By extending the JIT to support binary oriented regular expressions to identify malicious strings of code during dynamic recompilation, an anti malware system could be built. The downside of course is that performance will take a beating. This is simply to be expected, virtualization was always a stupid idea for anyone using it as anything more than a transitioning platform.

Re:No shit

[Anonymous Coward]

Holy shit dude, what translation script or code page are you running where an apostrophe maps to &#226 ;&#8364 ;(TM) ? That must have taken some work to make it three separate characters each with its own translated code.

Re: The Browser is now the desktop

[K. S. Kyosuke]

Except I was not the one being so authoritative about "an incredibly warped and messed up slant on cpu history". Register windows and register renaming have nothing to do with speculation. Register renaming was already present on the ACS-1 in the 1960 to support dynamic instruction scheduling.