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]

Can this be mitigated just by turning off HT?

Re: The Browser is now the desktop

[Anonymous Coward]

Nope, disabling SMT on both Intel and AMD makes the exploit slightly more difficult to execute but doesnâ(TM)t mitigate.

Itâ(TM)s pretty much impossible to mitigate these types of exploit completely without disabling speculative execution completely which isnâ(TM)t possible without savagely affecting performance for lots of different workloads.

We have had at least 6 different fixes for spectre now and none of them are complete, they never can be without going back to the drawing board for the speculation execution process in all modern cpuâ(TM)s. The horse has long since bolted and we are still trying to nail the door shut

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

[Anonymous Coward]

emacs was and still is the desktop.

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

[Anonymous Coward]

That is an incredibly warped and messed up slant on cpu history you have there

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.

The only producers who were slower and later than intel were AMD and Cyrix / VIA designs

Speculative execution and vector instructions were what kept the others ahead of intel for so many years

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

[Anonymous Coward]

Isn't the register renaming rather a feature of out-of-order execution? AFAIK this doesn't require speculation - just resolving dependencies, which are taken with 100% certainty.

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

[Anonymous Coward]

Nope.

Too many things wrong with it, from a weird kludgy protocol (a stateless protocol other a stateful connection), to awful versions of modern standards that run counter to what large scale modern development needs (HTML5).

Then there's the utterly useless default limits on local storage (5 - 10mb) which you have to build to the lowest common denominator on that make it useless on that front.

The web is just a serious of really poorly engineered hacks on top of other really poorly engineered hacks designed to try and emulate the desktop that ultimately end up in failure. There's a reason so many key apps from office software to editors, to games have lightweight web versions, but still tell you to fuck off to the desktop version if you want to do anything meaningful. The web is a house of cards, that's just waiting to collapse under the weight of all the hacks causing a realisation that it's best left to what it's meant for - document delivery, and sure those documents can be rich, such as videos, music, images, as well as text, but ultimately document delivery is the limit of it's ability to do things well; everything beyond that is just a pale version of what fat client software always did and still does offer in comparison. From gaming to photo editing, office productivity to software development, it's still all done better with fat clients.

The only way to change this is with a new set of technologies and a new set of standards designed to do what we actually want, using protocols that make sense for applications, and yes, a fairly language neutral JIT compiler at it's core as they're trying to do badly with WebAssembly. It doesn't mean support for this couldn't be enabled in a browser with app:// engaging the application stack instead of the document delivery stack as for the existing web, but it doesn't exist yet, in recent years all I've really seen are slightly shitter versions of the things we could already do badly in Flash/Java/XBApps/ActiveX for the last 20 years, done badly natively in the browser instead. That's really not progress, and shows the limits of the stack, the internet is desperate for a breakthrough of the kind I described above, and the only thing stopping it is the corporate cartels controlling the internet and refusing to back each other on pushing new ideas forward each wanting their own implementations which inevitably fail - Mozilla, Google, Microsoft, Apple, and Facebook. Until they're broken up and dealt with, we wont see much progress. Mozilla could do it if it sacked it's entire inept product team on Firefox and started again going back to it's origins as an open source organisation simply trying to make a better web, but as it's stands the staff their were too inept to even keep their browser top of the pile with a massive user base telling them exactly what they did and didn't want and them ignoring them and still running it into the ground regardless, not to mention the technical merits of Firefox fell through the floor with a problematic memory leak they refused to even admit the existence of for about a decade, abysmal security usually being first to fall in security competitions and just general bugginess and awful performance in the end. In fact, given this, maybe not Mozilla, because it's probably a lost cause, but something how Mozilla used to be in it's early days instead.

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

[Anonymous Coward]

He is stating his info like it's FACT. He even undermines other people in his post.

He is lying. And from the tone, it looks like he is woefully ignorant of the history.

Whether lying on purpose or by mistake, doesn't matter. A lie is a lie especially when you come across as a "I know it all, you are wrong and stupid" tone.

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

[Kaenneth]

The key problem with ActiveX on old Windows, is that once it was breached, there was no more security. These days, the user account doesn't have administrative access by default on Windows for a long time.

Anyway Meltdown/Specter are more problems on the server side, noone should ever run a web browser on a real server (download patches to removable media, then install them)

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

[Anonymous Coward]

ROWHAMMER was the first proof of concept of browser level memory exploits, and spectre triggered changes in the browser to reduce timing resolution.

This article is explicitly about WebAssembly bypassing many of those timing resolution protections (probably needed for the GL stuff) and you're going on about Server side bullshit. Its not javascript thats at fault here. Its WebAssembly.

Re:Who thought this was a good idea

[Anonymous Coward]

These days, the user account doesn't have administrative access by default on Windows for a long time.

NOBODY cares about administrative access. Everything sensitive is in the user's account.
Insert relevant XKCD here.

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]

> Everything sensitive is in the user's account.

Short of sandboxing, how would one set up a separate user account on Linux to run Firefox in it (thus without any access to the actual /home files), but still use it from the main user desktop?

Re:Who thought this was a good idea

[Anonymous Coward]

I don't tend to download an app, use it, delete it, then download it again, during which time it may be compromised. But if I clear my browser cache to be secure, it is what happens.

Re:Who thought this was a good idea

[Anonymous Coward]

Then it can't render the patches against Meltdown and Spectre ineffective.

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

[Anonymous Coward]

So javascript shouldn't exist either then? Or html?

Re:Who thought this was a good idea

[Anonymous Coward]

If JavaScript is so bad, go ahead and build a popular e-commerce/social network/anything other than just read only articles site that doesn't use it at all.
I'll wait.

Re:Who thought this was a good idea

[Anonymous Coward]

Permissions and ACLs?

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

[Anonymous Coward]

Your logins and credit card information are entered into Firefox, do I don't think sandboxing Firefox helps much.

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

[Anonymous Coward]

Is your job creating Strawmen?

Re:Who thought this was a good idea

[Anonymous Coward]

Java as programming language is different than Java applet as browser plugin. But you already know that, don't you?

Re: Who thought this was a good idea

[Anonymous Coward]

Your question means jack shit. Google for Christ sakes. There are multiple answers to the problem you stated, and they all don't use JavaScript.

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.

Re:Who thought this was a good idea

[Anonymous Coward]

Nope.

Re: Who thought this was a good idea

[Anonymous Coward]

Your question means jack shit. Google for Christ sakes. There are multiple answers to the problem you stated, and they all don't use JavaScript.

Cool, name one.
Unless you meant Google as an answer, in which case, lol. I guess tracking everything about the person is fine as long as it's server side?

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?

[Quzak]

JavaScript is cancer, and so follow that this WASM will also be cancer.

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?

[Anonymous Coward]

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

WebAssembly is closer to an intermediate format than machine code. It requires a VM to run in... indeed it shares the same VM as your good friend Javascript :)

(Don't get me wrong, I hate advertising networks and the general bloat of the web also, but let's not throw the baby out with the bathwater here.)

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?

[hcs_$reboot]

systemd is written in Javascript, actually

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?

[Anonymous Coward]

WebAssembly is a much safer interface than Javascript.

Good. Now I can be assured my malware won't be exploitable.

The summary makes it sound like it's some kind of x86 code, but it's not.

No, it's just designed to be readily JITed into native x86 code so it performs with close to native x86 speed. What better way to maximize attacking CPU bugs?

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.

Good thing this WebAssembly thing is kept far away from large attack surfaces like web browsers. I feel totally safe now.

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.

Yep, because the problem is the complexity of Javascript code. It's not the whole running whatever code (in a sandbox) some website wants me to run. You should the same sort of idiot who thinks so long as you can't gain root access on a system, it's no big deal that user accounts are full of worms and malware stealing passwords, clogging bandwidth, and burning CPU/GPU cycles for cryptomining.

You want to be positive about WebAssembly? That's great. But as others have pointed out, 99% of Javascript/WebAssembly/whatever in Web Pages should just die. The problem isn't per se the security of the language. It's that most web pages host advertisements and advertisers don't care about the costs they place on users because there's no real mechanism to retaliate when you can't segregate out which advertiser (and hence which company) is responsible.

Advertisers intentionally and malicious intertwine their ads with actual content. The day we can trust advertisers to sandbox their content appropriately, we may actual consider WebAssembly as something meaningful. As it stands, WebAssembly is just optimizing the shitshow that is most ad invested pages.

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?

[Anonymous Coward]

Everyone needs WebAssembly.

Javascript is a hack, literally created in one day because it was thought a scripting language was useful for the web. So long as any code is running on a site, it might as well be written in a safer language and compiled to bytecode for performance and safely.

Re: Who actually wants this?

[Anonymous Coward]

I hope that was a sarcastic post but if not the you need to spend less time worrying about app stores and spend more time dealing with your unhidable mental health problems

You clearly have problems separating fact from fiction and just described a fairly tale as reality. This is not healthy or normal and will lead to even greater levels of self delusion in the long term. Thatâ(TM)s not a good place for anyone to be and for most people it ends as a sad, bitter, lonely existence with a perpetual anger at Imaginary enemies and an inability to understand the world around you. In medical practice in most parts of the world we would call what you are experiencing derealization, a serious mental health disorder consistently correlated with social and other anxiety disorders.

I wish you good luck and hope you can find the strength to get the help you obviously need and are asking for

Re:Who actually wants this?

[Anonymous Coward]

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.

No, it's more like Java bytecode than x86 code, but somehow this doesn't sound too reassuring to me.

Re: Who actually wants this?

[Anonymous Coward]

That is frightening naivety and a huge mis understanding of what wasm is and the mechanisms it uses

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?

[Anonymous Coward]

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

It's GNU/Systemd, you insensitive clod!

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?

[Anonymous Coward]

Where can I buy a pair of those rose tinted glasses you're wearing?

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?

[Anonymous Coward]

WebAssembly is a much safer interface than Javascript.

Well, most anything would be safer.

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

[Anonymous Coward]

I'm running debian's packaged build of Firefox ESR. Two of those options don't exist and the other two are set to false by default.

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.

[Anonymous Coward]

Not the only detail missing. Slashdot editors do love FUD however.

Re:TLDR; using thread loops to measure time.

[Anonymous Coward]

Yes, dumbest summary I have seen in a long time of a non-issue.

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.

[Anonymous Coward]

Actually, making the timers fuzzy does block the easiest way to block Spectre in a browser. And if Webassembly lets things run on the hardware then it does bypass what browsers do to accomplish that, which does in fact remove most of the protection a browser provides from Spectre-class attacks. Yes, there are other ways to accomplish a browser-moderated Spectre attack, but they're harder and don't work as well.

Notice I use "Spectre-class" to describe the attacks. Some attacks work better than others. Meltdown is hard to trigger from a proper modern browser (though one might wonder if WA allows full hardware access.

Does this remind anybody of ActiveX?

Re:TLDR; using thread loops to measure time.

[Anonymous Coward]

Fumble fingers - fuzzy blocks easiest way to DO a Spectre attack...

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.

[Anonymous Coward]

Isn't that a built in javascript function?

if (Timer.fuzzing_level() > 5000) {
        figureOutFuzzingSequence(Timer);
        Process.hack_browser({ steal : "passwords" });
}

I swear I learned this in my community college courses, or was I mistaken?

Re:TLDR; using thread loops to measure time.

[Anonymous Coward]

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

The only proper fix would be to fix the CPUs. Only the CPU vendors can do that, and others can just try to mitigate the problems without being able to create real fixes.

Re:TLDR; using thread loops to measure time.

[Anonymous Coward]

That's why as part of the fixes they disabled shared buffer, i.e. no to Javascript events/threads could access the same buffer. Because this kind can be done without any WASM.
If they didn't port that mitigation to WASM that's not a surprise and they completely messed up.
It's also not an issue with WASM in general, but having a thread implementation and allowing those threads concurrent (or almost concurrent) access to a buffer.

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.

Category error

[Anonymous Coward]

Philosophers call it that: programmers call it "we checked the permissions after we loaded the cache".

The Multicians didn't make that mistake.

Re:Category error

[gweihir]

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

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

[Anonymous Coward]

Javascript and Web assembly may share ability, but they don't share implementation.

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

[Anonymous Coward]

Really? What makes you think that?

For chrome, firefox, edge and vivaldi they share exactly that implementation and virtual machine runtime

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:Thank you.

[Anonymous Coward]

Do not worry. This will be handled by the United States Cyber Sex Command.

Bad fit.

[Anonymous Coward]

What HTML is to E-Mail, JS is to browsers. Neither has been the same since, and a vector for all things bad.

Re:Bad fit.

[Anonymous Coward]

"Browser makers created WebAssembly to improve the speed of delivery and performance of JavaScript code"

It is this type of retarded fuckery that is destroying the Internet.

The problem IS NOT that Javascript is too slow. The problem is there's too fucking much of it. Slashdot's main page has 15 scripts on it. On other websites, I've seen pages with more than 30.

That is beyond absurd.

Re:Bad fit.

[Anonymous Coward]

thats right - bundle and minify all of your scripts into one batch

Re:Bad fit.

[Joce640k]

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

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

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

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: Bad fit.

[Joce640k]

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

Who actually wants this?-Broadband ISPs.

[Anonymous Coward]

But on the bright side it forces everyone to abandon dial-up, which BTW WAS a competitive industry unlike current broadband.

Ahhh history repeats itself

[Anonymous Coward]

And javascript strikes again!

So...

[hcs_$reboot]

patch the patch already!

You're Poettering was thinking?

[raymorris]

You're sure Poettering was *thinking* when he made systemd? Would you like to take this opportunity to revise that comment?

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:On the other hand

[Todd Knarr]

Webasm isn't progress, it's regress. It's a new way to run untrusted code from an unknown outside source directly on your CPU, which'll end up in the same place every other method for doing this has: being a source for an unending series of remote attacks until browser makers disable it. I'd've thought we'd've learned from previous iterations, but apparently some people are incapable of learning from other people's mistakes.

Re:On the other hand

[Anonymous Coward]

How is this any differently than downloading software and running it?

And how is the browser any worse of an attack surface than packages downloaded from the internet? Executing things from trusted sources is the only way to go any most people trust without any good reason (if your'e a linux user, are you really validating the sha1 of every thing you install? really? no, really? some do. vast majority - no).

No, not the same entirely because you can run this shit from any URL (like Flatpak or whatever all-in-wonder is the current norm?)

Flatpak has a MUCH greater attack surface.

WebASM is not bad at all, but questionable if its needed as its transferring processing requirements from providers to consumers.

You're old and reacting without thinking it through. I recommend going to a concert or attending a lecture at a university to get your brain working again.

Re:On the other hand

[Anonymous Coward]

When you download, _you_, user, do it. _You_ download a file from a dodgy place and _you_ run it.

But _you_ do not have control over what a browser does. This very website loads, whether you like or not, a lot of crap being run in my computer. If you are a geek and know what you're doing, you can end all evil and _disable_ javascript, cookies, etc. of follow someone else's advice and endup with a browser bloated of anti-crap plugins.

However, JS has an advantage over Wasm: given the time and some coding experience, you can sort of guess what it does (guess, because they are _all_ obfuscated). Wasm? not a chance. Free ticket for websites to run anything on your computer.

But let's not panic, it's not like computers (browsers) have been hijacked to mine money for other people or collected data for targeting "ads" purposes (sure). On top of that, given the better performance, that'll give yet another chance to increase the clutter in the web so that we reach 1000MB/s connections at home and the web still loads as fast as it did in the 1990s. Why let users fly in the web when there's so much crap that admins can put in...

Re:Noscript

[Anonymous Coward]

NoScript blocks javascript, but there are some sites (including this one) where at least some javascript must be enabled. If a site that requires javascript then chooses to process it through webassembly, and you have enabled javascript to see something, it will run the webassembly. If the site is compromised with an exploit that runs through it javascript to webassembly, well, you are (*&^&*().

NoScript is good. But it's not infallible. And if you are required to allow javascript to use a site, and set up NoScript accordingly, it doesn't help you. Other things like uBlock Origin and Privacy Badger may be needed to reduce the attack surface further, but in principle you can't avoid it entirely and still view web sites. So now what?

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: Thank you.

[Anonymous Coward]

Iâ(TM)m sure there is a 6 year old with downs syndrome somewhere that found that funny. Maybe

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:Noscript

[Anonymous Coward]

there are some sites (including this one) where at least some javascript must be enabled

This site works perfectly well without JS. Reading and commenting (like this very post I am making) can be done without any scripts, even on the /..org domain.

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.

True visionaries

[Anonymous Coward]

I would never think that link's developers would have such a vision, it's going to be the most secure browser out there given all the crap "standards" are implementing. All I want is to visit a bloody website and read the content. Wasm, JS, cookies... all that crap is not of interest for any user, but tools by the webmasters to monetize. Gosh just ask people to pay a fee or GTFO, but do not clutter the web...

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:No shit

[Anonymous Coward]

what translation script or code page are you running where an apostrophe maps to &#226 ;&#8364 ;(TM)?

It's a bug in the JIT. Please file a bug report.

Re: No shit

[Anonymous Coward]

Slashdot needs to fix this shit. If I type thingâ(TM)s, on my iPhone it may not work well.

WebAssembly

[Anonymous Coward]

WebAssembly... From the same place in hell where WebUSB spawned (and before that, ActiveX). Browser developers should not be relied on for security.

And no, Javascript is not slow. Moronic web-"developers" including 25 moronic frameworks to fill up the page with moronic animations and ads to prevent people from reading the actual content{1] is what makes Javascript slow.

[1] if any - the latest trend in web development is to have less information following each headline than in the headline itself.

It's not their remit to prevent it.

[Anonymous Coward]

That responsibility, lies with the hardware manufacturer itself for fixing and making the workaround for it, technically it's not even the OS that should be 'guarding' against it

The CPUs are faulty, plain, simple, and should now be regarded as trash.

In addition, now would be a good time to dump the steaming pile of polished shit called x86 and move to something without any legacy crud (not spectre related), but literally stop trying to polish that turd and use a properly designed and well thought out platform like arm v8 or heck, even itanium.

Re:Noscript

[Anonymous Coward]

wasm IS Javascript. It's just Javascript written in a weird and special way to allow special optimizations to happen.

Re:Block infecting 3rd party scriptsources

[Anonymous Coward]

Stop spamming your ineffective security software.

How much I "obey" you (lol, not)

[Anonymous Coward]

See subject & read 'em & weep: Get over yer delusions of grandeur! Ya don't own me: I "PWN" U https://it.slashdot.org/comments.pl?sid=12270344&threshold=-1&commentsort=0&mode=thread&pid=56841844/ easily, chump... lol!

* Ah, this is (& I haven't said THIS in awhile but you're forcing me to) just "too, Too, TOO EASY - just '2ez' & it ALWAYS is vs. UNIDENTIFIABLE anonymous STALKER do-nothing "ne'er-do-well" wannabes & wastes of LIFE like you... hahahaha!

APK

P.S.=> Lastly - /.ers CLEARLY DISAGREE on the EFFICACY of my ware (& it's quality etc.) & where's YOURS they say THIS about https://it.slashdot.org/comments.pl?sid=12270344&cid=56841850/ - lol, it's NOT since you're a trolling STALKING LAZY waste of air JEALOUS "Lil' Jowie"... apk

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.

ActiveX, Flash, Java revealed the problem

[goombah99]

The idea of the Browser as the Desktop is a good one. While there's the obvious inefficiency of an added layer, it seems to be better than other ways of remote application serving. In theory.

The problem is that for peak efficeincy all of the past solutions have pierced the veil of the browser and drilled down close to the OS metal.

ActiveX, Flash, Java all are pretty much dead because they have proven that security can't be achieved ever. It's just a momentary state before someone discovers the next security hole.

Someone could say, well were smarter now so we'll design a model in which security is the first class citizen. Well call in WebASM.

Now we have proof that WebASM has a security hole.

The comeback argument is "hey, that's not a security hole in WebASM, it's a security hole in the processor that WebASM runs on." But if you think about it, that's true of every other security hole. Every other security hole, say java, generally got privledge escalation by using the OS to overwrite some critical config, or accessing files or memory that should not have been accessible had the OS been configured to keep it sandboxed.

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

I do note that the key problem does seem to come out of the "acceleration" part of it. While javascript and Html5 have their issues, it seems like most of those issues happen at the browser containment layer not at the OS/metal layer. Thus I speculate the security model has much more chance of working for these than the accelerated ones that bypass the browser layer.

But that's just the thing. All this "well this time we'll design it to be secure" always fails because no one, not me or not you, really can be sure of the things were saying. This is why I'm pointing to history rather than trying to prove it can't be done by some logical argument. I'm talking out my ass but at least I have history on my side.

My basic feeling on security is that until people actually start using the sandboxes the dtrace OS designers have built into OSX and Linux, that everything else is just bunch of fingers in the dike. I simply don't understand why these sandboxes see such little use. Once they are used then adding on more layers in the security model on top of that onion layer makes more sense to me.

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: ActiveX, Flash, Java revealed the problem

[Anonymous Coward]

No, we do not have a security hole now. We might have had one if WebASM devs had enabled functionality they did not enable yet. Also, WebASM does not bypass the browser.

Oh well. No matter how much FUD is thrown at it, webASM is bound to suceed. Businesses are searching for a way to unify back and frontend. Either we have Node.js (yuck!) or we use a decent programming language instead of a scripting language for the web.

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

[Anonymous Coward]

The only reason they disabled it was because it was a case where the processor defect was known

The exact same thing applies to the original Javascript mitigation, or even the Linux Kernel mitigation. The only reason these were made was because the defect was known. So in that regard WebASM is not weaker than most other technologies, not even from Javascript which had the exact same issue.

Rather than judging the tech based on what's not in its domain, you should look at what is offered in the tech's domain. Currently there are two ways to use javascript: Either directly as a backend for other languages. The former suffers from all of Javascript's drawbacks and splits front from back end, web from system. Other languages allow us to use other programming paradigms on the web, and keeping front and ui aligned meaning less impedance mismatch. They also offer significant static help to prevent security issues like XSS. The latter is a poor backend, obviously inferior to something designed to be a backend.

Re: ActiveX, Flash, Java revealed the problem

[Darinbob]

I vote for decent programing language instead of Javascript.

A web browser feeding compiled remote source toCPU

[Anonymous Coward]

it is so certain that literally nothing could go wrong that i can't even

Block infecting 3rd party scriptsources

[Anonymous Coward]

See subject & APK Hosts File Engine 2.0++ 64-bit for Linux h t t p : / / a p k . i t - m a t e . c o . u k / A P K H o s t s F i l e E n g i n e F o r L i n u x . z i p (remove spaces between characters & download).

Yields more security/speed/reliability/anonymity vs. any SINGLE solution (99% of threats = hostnames vs. IP address that most firewalls use) more efficiently/FASTER + NATIVELY 4 less!

(Vs. "Bolt on 'MoAr' illogic-logic" competitors slowing you, hosts speed you up 2 ways (adblocks + hardcodes u spend most time @) vs. competition loaded w/ bugs (DNS/AntiVir) + their overheads (messagepass ('souled-out' to advertiser addons) + filtering drivers) & their complexity leads to exploitation).

* ONLY 1 of its kind in GUI on Linux/BSD!

(Much better vs. Windows model in speed & efficiency + new "merge" feature)

APK

P.S.=> Next post subsequent are /. users' review of it on Windows... apk

Registered /.ers review of the Win64 model

[Anonymous Coward]

Your software is just fine - well written, functional... I'm going to continue using the Host File Engine by mmell February 17, 2017

(APK's work), I've flat out said it's good by BronsCon February 11 2016

his hosts program is actually pretty good by xenotransplant August 10 2015

his hosts tool is actually useful for those cases in which one does indeed want to locally block stuff outright while consuming minimum system resources by alexgieg September 25 2015

I like your host file system by Karmashock September 09 2015

I do use APK's host file on all my systems at home by OrangeTide December 01 2017

I personally use a HOSTS file blocker produced from a genius called APK by 110010001000 October 27 2017

* See subject: Best part's the Linux 64-bit model's faster/more efficient (does 2x the work in 1/2 the time)

APK

P.S.=> Enjoy a faster/safer/more reliable internet... apk

Re:Noscript

[Anonymous Coward]

Use uMatrix instead of NoScript. It's more fine-grained than NoScript. Or you can use NoScript in addition of uMatrix. In this case NoScript is not used as script blocker, but as additional security features (XSS prevention, etc).