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

The Browser is now the desktop

[Anonymous Coward]

Discuss.

Re:The Browser is now the desktop

[gweihir]

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

Re: The Browser is now the desktop

[Anonymous Coward]

It's pretty much impossible to mitigate these types of exploit completely without disabling speculative execution completely which isn't possible without savagely affecting performance

The performance you would get with Speculative Execution disabled is the performance we should have had all along.

Instead of concentrating on making CPUs better and faster and more efficient, Intel decided to cheat, AKA, Speculative Execution. And It worked wonderfully. Until it didn't.

Speculative Execution is little more than a marketing gimmick created by Intel so they could claim that their chips were faster than the competition, which then forced other companies to do the same thing, so it wouldn't appear that they weren't "competitive".

Re:The Browser is now the desktop

[Bing Tsher E]

No, the Tab Window Manager is the desktop.

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.

Re: The Browser is now the desktop

[angel'o'sphere]

Stop using the word Lying when someone makes a mistake.
As you cited no sources, I could as well say: you are lying.

Especially considering the PowerPC and SPARC part. They had register windows and register renaming, I would bet $100 they had speculative execution as well, because register renaming makes not much sense without it.

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.

Re:The Browser is now the desktop

[Darinbob]

Well, now you execute random code from random third parties and will start wondering why you're getting so much malware all of a sudden. Why is noscript become popular, not because javascript is too slow, but because that's where so many malware, spying, tracking, and advertising attacks are coming from.

Re: The Browser is now the desktop

[Darinbob]

No, RISC wasn't supposed to be "simple", it was supposed to simplify just one part of the CPU so that those resources could then be used to speed up other parts. Ie, greatly simplify the instruction decoding and then you can add more registers, cache, pipelining, and so forth.

Re: The Browser is now the desktop

[edwdig]

It's pretty much impossible to mitigate these types of exploit completely without disabling speculative execution completely which isn't possible without savagely affecting performance

The performance you would get with Speculative Execution disabled is the performance we should have had all along.

Instead of concentrating on making CPUs better and faster and more efficient, Intel decided to cheat, AKA, Speculative Execution. And It worked wonderfully. Until it didn't.

Speculative Execution is little more than a marketing gimmick created by Intel so they could claim that their chips were faster than the competition, which then forced other companies to do the same thing, so it wouldn't appear that they weren't "competitive".

Speculative execution is a massive improvement. It gets rid of a ton of CPU stalls and lets you execute more instructions at the same time. It's one of the biggest improvements to performance that Intel ever added.

You're confusing the concept of speculative execution with a quirk of Intel's implementation. Intel's flaw is the CPUs don't check memory access permissions until the end of speculative execution instead of the beginning. It's a small performance optimization. There was no intent to cheat here. About 25 years ago, they realized they could get a small performance gain by delaying the permission check a little bit. The behavior has been documented the entire time. If it was obvious that the design was problematic, people would've found the flaw a long time ago.

Re: The Browser is now the desktop

[DRJlaw]

Especially considering the PowerPC and SPARC part. They had register windows and register renaming, I would bet $100 they had speculative execution as well, because register renaming makes not much sense without it.

You'd be wrong about PowerPC (not until 1994) and SPARC (not until 1995), but you can rest easy in that you're merely reckless and untrustworthy rather than lying and untrustworthy.

I expect my $100 now.

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

[Anonymous Coward]

Now that net neutrality has ended only trusted websites will be allowed!

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

[AHuxley]

Going to have to buy a Gigabyte BRIX just to do the internet on? Keep the internet away from the computers?

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.

Re:Who thought this was a good idea

[Anonymous Coward]

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.

So because everyone's doing it, it's fine and we should be quiet huh? We shouldn't question whether or not this is an ideal method of doing what we need to, or if there are safer ways?

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.

See also any hypervisor. So your argument is pointless as the entire OS can be sandboxed if you want it to be. Also, HTML is interpreted so even the most basic web browser session is running "unverified code". So where does the browser improve anything?

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.

So, you admit you block as much of it as possible, and still are trying to defend the status quo.

Here's a hint: Treating any random remote machine as a safe code source is a bad thing. It goes from bad to worse when that crap is given auto-execute privileges, and for that there is no excuse. Especially in this time and day when we have the mentality of: "Everything must be a web app so I can fire the nukes from the head on my iPhone!"

If this crap wasn't being constantly abused for a desktop replacement, we'd have a lot less problems. First and foremost, it would be much harder for malware to infest a machine. Second, we wouldn't have to worry about over exposing hardware to random sites. Like giving a site access to the MIDI sequencer(?) or the gyroscope. I thought the whole damn purpose was to rely on the browser, not side step it and run code directly. What happened there? Third, much less privacy violations. Hard for ADs to spy if they can't execute anything. Better yet the social media sites have no data to scoop up either unless you intentionally put it in, which is the way most people think it works.

Desktop apps exist for a reason. Yes, we don't like having to install apps on our computers. We want to avoid doing anything with computers as much as possible. But, running random code from some random source is never a good idea when it comes to protecting any machine. The fact that it has become the defacto standard, is a failing of all of us, and one we need to fix. Especially in this era of handholding everyone, the best thing we can do is to remove the easist problem vector.

Re:Who thought this was a good idea

[mlyle]

It's reasonable to expect that naughty code can be contained-- we have process containment and virtual machines and OS privileges for the purpose. But side channels, like Spectre etc, make that more difficult.

Re:Who thought this was a good idea

[HiThere]

Unfortunately, several modern computer languages do just that. Rust even does that and claims to be secure. (True, it's the tool chain, not the base language. I'm not sure that makes things better.)

Re:Who thought this was a good idea

[Darinbob]

They just have different goals than the users is all. Internet decision makers want money from advertisers so they will do everything in their power to shove more of it at us, and more and more targeted ads. The users just want to see kitten videos and what their friends are up to.

Re:Who thought this was a good idea

[Darinbob]

It was also a stupid idea from the start. It was Windows only and invented primarily to try and enforce more customer lockdown. Like so many Microsoft ideas, the priority was to push features out first and worry about security issues never.

Re:Who thought this was a good idea

[Darinbob]

Isn't that what they said about Java?

Re:Who thought this was a good idea

[Darinbob]

No, I don't normally run unverified code from third parties that I have never heard of. I used to have to manually download and install programs. Now programs run by themselves from sites I don't know about, just because some loser website uses third party advertisement and analytic sites to try and monetize a blog.

Re:Who thought this was a good idea

[Darinbob]

Why is why I use noscript.

(except for work, where the new parent company is so in bed with Microsoft and the Cloud that you literally can't change your password if you have noscript, even if you've whitelisted all the scripts, so I have a second browser profile just for official work related activities)

Re:Who thought this was a good idea

[Darinbob]

But why would I want to do that? I've got a real job that doesn't involve exploiting customers.

Re:Who thought this was a good idea

[thegarbz]

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

What do you prefer?

A walled garden app store?
A system requiring signed executables approved by he who can't break into the phone business?
A complete lockdown with only the software your computer came with able to run?

What could go wrong? We could own our computers and have the freedom and power to make them do what WE tell them to. How horrible.

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?

[fahrbot-bot]

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.

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

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?

[charliemerritt03]

Mod him up. Websites should be responsible for sending me where I didn't ask to go. I would call them 3rd Party Ad Farms.

Re:Who actually wants this?

[bhcompy]

Clearly safe, as the article posits.

Re:Who actually wants this?

[bobby]

You're sounding like my very first posts here on /. 20 years ago. Yep, I'm gonna say it: "nobody every listens to me".

I understand art and tricky artistic and "interactive" "content". In other words, I see some value in javascript. I could argue that most of the functionality should be in html / css, but sometimes a programming language like javascript is the best and maybe only way to get some things done.

My main gripe is with browsers and what they're allowing javascript and WebAssembly to do in and to our computers.

And of course OSes which allow evil to happen.

And now we can't trust hardware.

Web browsers need to be run in small, disposable containers.

Preferably on dedicated computers that can be re-imaged frequently.

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?

[mnemotronic]

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

...snipsnip...

I respectfully disagree. Attack surface is the result of a set of fundamental design decisions based on knowledge, or lack thereof, of the operating environment (OS and browser), toolset (compiler), and communication protocols. "Knowing what runs" seems to be more of a personal requirement to inspect the webpage source code. Even if you could reverse compile WASM code (which will obviously happen if it hasn't already) and inspect it, that doesn't help if the underlying pcode interpreter has security vulnerabilities unbeknownst to you.

Re:Who actually wants this?

[JaredOfEuropa]

That’s not unreasonable. Legislators (especially here in Europe) are increasingly leaning on online platforms to apply filtering of 3rd party content. Mostly to address copyright violations, but also against undesirable opinions (“hate speech”). And those platforms will be held responsible for anything that gets through.

I am opposed to such a priori censorship, but if we’re going to apply it, I don’t see why it shouldn’t extend to ads and code. In fact since the case for up front filtering is the “far reaching consequences and extensive damage resulting from publication”, I hold that it should be applied not to opinion but to code.

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?

[phantomfive]

Webassembly is binary bytecode. It's something different.

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

Re:Who actually wants this?

[vtcodger]

Y'know what -- Compuserve and Fidonet via a 1200 baud modem in 1994 was in many ways a better user experience than the modern internet. There are some useful things on the Internet -- Wikipedia, Stack Overflow, etc. And it's sort of still possible to get news content despite the best efforts of advertisers to make that as unpleasant an experience as possible. But overall, I think the Internet perhaps even more than US commercial TV has become part of FCC commissioner Newton Minnow's Vast Wasteland.

Re:Who actually wants this?

[jittles]

You're sounding like my very first posts here on /. 20 years ago. Yep, I'm gonna say it: "nobody every listens to me".

I understand art and tricky artistic and "interactive" "content". In other words, I see some value in javascript. I could argue that most of the functionality should be in html / css, but sometimes a programming language like javascript is the best and maybe only way to get some things done.

My main gripe is with browsers and what they're allowing javascript and WebAssembly to do in and to our computers.

And of course OSes which allow evil to happen.

And now we can't trust hardware.

Web browsers need to be run in small, disposable containers.

Preferably on dedicated computers that can be re-imaged frequently.

I'm not advocating that we nuke javascript from orbit. But right now it's like the wild wild west. Push some new framework from some 3rd party website that you have no control over because it "does cool things". Who cares, right? It's not your machine that is running the code. It is running on someone else's machine. At least, that is the attitude that these developers seem to have. I pretty much block all javascript content and the internet does more or less what I need it to do.

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.

Re: Who actually wants this?

[Miamicanes]

> That would likely result in fewer ad networks pushing viruses around the internet since there would actually be someone to hold responsible for it.

It would also be mostly a moot point unless the site is owned by a major corporation, since an average blogger -- even one who earns enough from it to live on -- is effectively judgment-proof by virtue of not having enough assets to sustain more than one or two losses (and that's if they lose by virtue of not hiring a lawyer to fight... if they DO get a lawyer, they won't have anything left to sue for anyway by the time their legal fees are paid).

That said, perhaps the time has come for a new type of code-signing certs that indemnify the holder & insure them for $1/10/100 million... but allow the issuers to impose their own security & auditing requirements. So you might decide to blindly allow code signed with a $100 million cert to silently execute, allow code signed by a $10 million cert to either run silently in a sandbox or prompt for approval, allow code signed by a $1 million cert to run sandboxed if it's same-origin as the site itself or fail quietly if not, and require that unsigned code be delivered via https, with appropriate content security policy headers, for it to do anything besides fail silently.

Main rationale for the final rule/exception: most javascript-enabled malware comes from third-party code hosted by someone else & used without constant scrutiny by the linking site. Forcing site owners to host it locally & configure their server to enforce content security won't eliminate the problem, but it will mitigate most of the low-hanging drive-by fruit.

Re:Who actually wants this?

[Darinbob]

I wouldn't mind ads on the web if they were actually curated by the web site owners. Instead these web site owners have handed over their responsibilities to third party sites.

Re:Who actually wants this?

[Darinbob]

Knowing what runs means that if I go to xyz.com then ONLY scripts and code from xyz.com should be allowed to run. In reality when I thought I was looking at someone's blog I actually end up being tracked for advertising purpose by third party sites I've never heard of. Javascript is a popular for malware precisely because customers don't know where all these scripts are coming from, and the original web site owner probably doesn't know either.

What this means is that because I use noscript, I can only view about 10% of the web, and that's shrinking every day. But there is no viable alternative to this.

Re:Who actually wants this?

[DamnOregonian]

Even FTM is misleading: "The technology is a compact binary language that a browser will convert into machine code and run it directly on the CPU."

That is in fact not misleading at all. It's so true I'm almost shocked at its accuracy.
WebAssembly is in fact a compact binary language that a browser (at least most) will convert into machine code on the fly and run directly on the CPU via their wasm-optimized JavaScript JIT compilers.

Re:Who actually wants this?

[DamnOregonian]

Different, but also very much the same.
It was designed to run on an engine that had asm.js optimizations in place, and was itself merely a binary (and descriptive assembly) format for applications that were designed to run on an asm.js optimized VM.
The initial versions of WebAssembly were in fact demoed using asm.js shims, and currently, WebAssembly appliations can be converted to asm.js on the fly for browsers that don't support the binary format. WebAssembly introduces even more restrictions to the operational set than asm.js did so that the optimizations required to make it fast could be standardized and implemented on more platforms easier.

Re:Who actually wants this?

[bobby]

Yeah, again, I completely agree and if you look at my first post 20 years ago, you'll see I've felt that way for a long time. I guess I've softened slightly, but I could live without javascript. Main reason I hate it: almost all malware needs it as the main mechanism of action.

Re: Who actually wants this?

[jittles]

It would also be mostly a moot point unless the site is owned by a major corporation, since an average blogger -- even one who earns enough from it to live on -- is effectively judgment-proof by virtue of not having enough assets to sustain more than one or two losses (and that's if they lose by virtue of not hiring a lawyer to fight... if they DO get a lawyer, they won't have anything left to sue for anyway by the time their legal fees are paid).

I'm perfectly okay with that as long as some small timer isn't hosting content on behalf of a major corporation. I don't typically visit Joe The Plumber's blog, but when I do, he likely does not have the main page content hidden unless I enable javascript. Yet a large number news organizations and many other large companies do exactly that. I'm happy to run their script content, I trust them enough for that. But I do not trust every single 3rd party script repo or CDN they choose to use on their website. They're also the ones most likely to be targeted by drive by download ads since they have such a large audience.

Re:Who actually wants this?

[mnemotronic]

... because I use noscript, I can only view about 10% of the web, and that's shrinking every day. But there is no viable alternative to this.

Clay tablets, pointed sticks and swallows (using Unladen swallow Delivery Protocol)

Re:Who actually wants this?

[Darinbob]

I have a clay tablet. It says "Enoch's slightly used sheep, get two for the price of one!"

Re:Who actually wants this?

[mnemotronic]

I have a clay tablet. It says "Enoch's slightly used sheep, get two for the price of one!"

Go with the sheep. The chickens died. And before I could get my merit badge dammit.

Hmm ...

[fahrbot-bot]

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.

And how about in the Web *user* community where the soon-to-be-compromised browsers will be running? As someone else said here, I want less Javascript not more - and certainly none with direct access to my hardware. So... anyway to disable WebAssembly in FF? (Asking for a friend)

Re:Hmm ...

[vtcodger]

"And how about in the Web *user* community where the soon-to-be-compromised browsers will be running?"

Users? Who cares about users? (As long as they don't use ad-blockers)

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:Hmm ...

[bhcompy]

My understanding is that NoScript blocks it

Re:Hmm ...

[Bing Tsher E]

Same thing for Seamonkey on x64 Windows.

Re:Hmm ...

[mnemotronic]

"And how about in the Web *user* community where the soon-to-be-compromised browsers will be running?"

Users? Who cares about users? (As long as they don't use ad-blockers)

Heard a great quote; can't remember where. It's probably a mimi or fifi or meme or whatever by now:

If you're not paying for the product, you are the product.

And as it turns out, even if you're paying for the product, you are product.

Re:Hmm ...

[Anonymous Coward]

https://github.com/stevespringett/disable-webassembly

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.

Re:TLDR; using thread loops to measure time.

[gweihir]

If your security is dependent on preventing precise time measurements, it is broken anyways. You can always measure time precisely in some fashion, may just take a little longer. But thanks for the info. I suspected as much, but now I can do without reading the article.

Re:TLDR; using thread loops to measure time.

[gweihir]

First, fuzzing timers is difficult to do securely. If an attacker can figure out the fuzzing sequence, they can use fuzzed timers without problems. If an attacker can measure the fuzzing in parallel, the same applies. And second, it usually just means measurements take longer, unless you actually quantify time coarse-grain for everything (again, difficult to do and even more difficult to do securely).

Basically, preventing precise time measurements is a dead end as a security measure. Sure, may take a little longer to generate exploit code, but it will still be possible. The only sane stance is that attackers will have precise time measurement available.

Re:TLDR; using thread loops to measure time.

[gweihir]

Well, anybody who has not at least one deranged troll stalker clearly has nothing worthwhile to say. So thanks for validating me.

Re:TLDR; using thread loops to measure time.

[thegarbz]

If your security is dependent on preventing precise time measurements, it is broken anyways.

I want to flip that on it's head: If your exploit is dependent on precise time measurements on a system you haven't characterized, running processes and memory which is not in your control looking for something that may or may not be there, your exploit is broken.

I will wager short of an actual state targeted attack by an inside person, or a hacker breaking out of his virtual machine on someone else's iron which is he currently using, Spectre and Meltdown won't have any practical implications outside of a lab.

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

[fahrbot-bot]

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

I'm not familiar with the implementation details of WebAssembly, but the above doesn't mean the reverse is (or always will be) true. Just like one can embed assembly in C (using the "asm" keyword), I wouldn't be surprised to see something like that in WebAssembly at some point -- and macros, like "ifdef/define" to allow conditional compilation.

(Developers may be clever, but are often not the most clever among us.)

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

[hcs_$reboot]

Anything you can do in WebAssembly, you can do in JavaScript

And roughly everything you can do in assembly you can do in C. But C does some extra work, checks or registry backups you might not need, and thus asm will be faster. Webasm is of course not as “free” as asm, but Javascript does even more checks and other side work compared to C, making it slower.

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:Sigh...

[phantomfive]

Webasm is of course not as “free” as asm, but Javascript does even more checks and other side work compared to C, making it slower.

The slowest thing in Javascript isn't about safety (arguably the opposite), it's that each variable access is actually a hash lookup. You can't really optimize that out (although you can make it faster to some degree).

Re:Sigh...

[angel'o'sphere]

WebAssembly is not the same as Asm.js (which is subset of JavaScript)
WebAssembly is a bytecode similar to C#/.Net bytecode or Java bytecode.

However it runs in a sandbox like JavaScript and has an API to the JavaScript engine.

Re:Category error

[gweihir]

Engineers call it a bad fuckup, probably caused by marketing demanding speed over everything else.

So...

[hcs_$reboot]

patch the patch already!

On the other hand

[hcs_$reboot]

the real culprit here is the CPU. Let's not stop all progress (and webasm is progress) due to other components bugs. Of course mitigation has to be implemented (by the browser), but please let webasm follow its improvement path.

Re:Bad fit.

[Joce640k]

Then convert them to a binary-encoded format for compactness and faster parsing.

Do I need WebAssembly?

[OrangeTide]

To access my bank account? My email? Social media?

Obviously not, given that I access them today without it. Wasm is a micro-optimization that becomes irrelevant with faster CPUs, more RAM, and better optimization of JavaScript. The gains are really linear in an area that has produced exponential improvement in the past.

I guess if you don't want everyone seeing your source code to the client side half of your website you might be interested in Wasm. I'm less than impressed by security-through-obscurity and copyright paranoia.

Re:Do I need WebAssembly?

[Fly Swatter]

To access my bank account? My email? Social media?

I still believe one of these things does not belong on the internet.

Well that's the basic idea behind it

[Casandro]

The whole idea behind WebAssembly was to make surfing the web insecure by downloading and executing code which is only shielded from the rest of the system by some magical concept called the sandbox.

Now since Rowhammer, Spectre, Meltdown and possible future problems, we should know that sandboxes don't work. Any form of turing complete code can be used as an attack vector. Even with a hypothetical perfect sandbox you can still abuse it for crypto-mining.

Re:Well that's the basic idea behind it

[Anonymous Coward]

Sandboxes do work. They're just not the 'magical concept' of your delusion.

Re:Bad fit.

[Anonymous Coward]

Considering that you need to write in C, C++ or Rust if you want to build a wasm app right now, you're not just avoiding JS, you're also preventing JS devs from writing the app (stringing together a bunch of Node.JS frameworks and libs).

That's the real win right there

Can I switch it off

[aepervius]

Well thought out does not matter, well implemented without flaw DOES matter, and unless webassembly has some kind of mathematical proof , I don't want it enabled on my PC. All I want is : can Is witch it off... ?

Re: Bad fit.

[Anonymous Coward]

Nonsense, you can write wasm in any number of languages that have a flexible bytecode compiler / interpreter stack. One of our juniors has been playing with wasm in Visual Basic this week and you can use any of the .net languages. Or you can use JS or create by hand or literally 20+ other methods including simple JS bytecode generators. MS is even working on an extension to wasm to bring a reduced but fully functional .net stack into client side browsing through wasm

You have no idea what you are talking about

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.

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.

Not the right place for mitigation, anyway

[edtice1559]

We've had this discussion before but it takes a lot to exploit a speculative execution bug. These are unlikely to ever be used on a mass attack but rather only in targeted activities. If you're machines are high-value targets, you should (a) have the kernel mitigations enabled even if they have a performance degradation, (b) not be browsing random sites at all. Delivering a SPECTRE attack via JS and extracting something sound like a *fun* project, but it's unlikely to yield any valuable bounty against the average user. It makes no sense to discuss this in the context of wasm.

Re:ActiveX, Flash, Java revealed the problem

[Anonymous Coward]

So this proves that WebASM is just another log on the ActiveX, Flash, Java fire of failed acceleration technologies for remote application services.

Exactly as pretty much everyone predicted. I believe that most people knew WebAssembly was an amazingly bad idea the very first time they heard of it.

When its proponents described it, even putting it in the very best light, it sounded horrible. And things went downhill from there. It's totally just another ActiveX, just like the people who made it warned us it was going to be. Google promised it would utterly suck, and they kept that promise.

Re: Bad fit.

[sound vision]

Or just skip the last step, since you have already got to adequate performance, and want to keep the architecture secure.

Re: ActiveX, Flash, Java revealed the problem

[goombah99]

The only reason they disabled it was because it was a case where the processor defect was known before they activated it. How many other processor or OS defects do we now know about? If it had been activated and then we discovered the security issues the platform had would they deactivate it later and break all of the web services already deployed?

your answer is weak in this regard.

Re: ActiveX, Flash, Java revealed the problem

[Darinbob]

I vote for decent programing language instead of Javascript.

Re: Bad fit.

[Joce640k]

Why is an intermediate binary format less secure than an ASCII format?