WebAssembly Becomes W3C Standard, Reaches 1.0 (thenewstack.io) 78
An anonymous reader quotes Mike Melanson's "This Week in Programming" column:
WebAssembly is a binary instruction format for a stack-based virtual machine and this week, the World Wide Web Consortium (W3C) dubbed it an official web standard and the fourth language for the Web that allows code to run in the browser, joining HTML, CSS and JavaScript... With this week's news, WebAssembly has officially reached version 1.0 and is supported in the browser engines for Firefox, Chrome, Safari, and Internet Explorer, and the Bytecode Alliance launched last month to help ensure "a WebAssembly ecosystem that is secure by default" and for bringing WebAssembly to outside-the-browser use.
Of course, not everything is 100% rosy. As pointed out by an article in The Register, WebAssembly also brings with it an increased level of obfuscation of what exactly is going on, giving it an increased ability to perform some surreptitious actions. For example, they cite one study that "found 'over 50 percent of all sites using WebAssembly apply it for malicious deeds, such as [crypto] mining and obfuscation.'" Nonetheless, with WebAssembly gaining this designation by W3C, it is, indeed, time to pay closer attention to the newly nominated Web language standard.
Of course, not everything is 100% rosy. As pointed out by an article in The Register, WebAssembly also brings with it an increased level of obfuscation of what exactly is going on, giving it an increased ability to perform some surreptitious actions. For example, they cite one study that "found 'over 50 percent of all sites using WebAssembly apply it for malicious deeds, such as [crypto] mining and obfuscation.'" Nonetheless, with WebAssembly gaining this designation by W3C, it is, indeed, time to pay closer attention to the newly nominated Web language standard.
Nothing to learn. (Score:2)
Your compiler will compile to it. Certainly if it is using LLVM.
The magic is getting access to the browser APIs!
Re: (Score:3)
The King is Dead, Long live the King! (Score:3)
Goodbye ye awful Flash, Silverlight, and client-side Java! Welcome glorious Web Assembly!
Same old, same old. (Score:5, Interesting)
Flash used ActionScript, which was just JavaScript with types, which modern JS can do too, and compiled it to bytecode, like WebAssembly, to be run on a VM... which happened to get told by a browser where to render and what input to take.
Java has nothing to do with the web. It is a regular programming language, generating regular programs and libraries and such. That happen to run on a VM. Like WebAssembly. Except with many more years of optimizations, fixes and improvements. There just happened to be VM runner for it, that also go told by a browser ... (you know the rest).
WebAssembly will have exactly the same problems as those before it. Because it is the same again. (Actually possibly even shittier.)
Except this time good luck disabling it or trying to kill it!
It'll definitely be fun times for black hats!
Fuckin' direct GPU access! "Sockets"! And all you have to do to get somebody to run your code on their machine, with no checks, is to post a link to it! (No, repeat after me: A VM is not a security solution!)
Re:Same old, same old. (Score:4, Informative)
Java has nothing to do with the web.
Clearly you're too young to remember applets.
Re: (Score:3)
WebAssembly will have exactly the same problems as those before it.
Flash and JavaScript were quickly slapped together by people that put little thought into design and zero thought into security.
Java was designed as a general-purpose programming language and was only later wedged into browsers.
Way more thought went into WebAssembly. It is possible that there may be some security holes, but much less likely that with any of the alternatives.
Re: (Score:1)
It's impossible that there won't be some security holes.
Meanwhile, we can run regular applications on our hardware and not just what some 'web developer' slings together.
Not quite as platform-specific (Score:3)
Meanwhile, we can run regular applications on our hardware
Provided that the application that you want to run is made for the hardware and operating system that you have. Good luck building and running an application that uses Cocoa on anything but a Mac.[1] For comparison, WebAssembly is designed to work the same way on different brands of CPU and different brands of operating system.
[1] I've asked a real Mac app developer, and no, GNUstep is not complete enough.
Re: (Score:2)
I've asked a real Mac app developer, and no, GNUstep is not complete enough [to be an adequate substitute for Cocoa when building Mac apps off macOS].
Do you have a picture?
Lior Halphon is the maintainer of SameBoy, a Game Boy emulator [github.io]. Basic features of SameBoy work on all platforms that support SDL2, but the video memory viewer is currently Mac-specific. Unfortunately, neither his Twitter microblog [twitter.com] nor his GitHub account [github.com] appears to have a face reveal.
Re: (Score:2)
Re: (Score:1)
Flash used ActionScript, which was just JavaScript with types, which modern JS can do too, and compiled it to bytecode, like WebAssembly, to be run on a VM...
I suppose the above statement is true, but the vm that hosts WebAssembly is the javascript engine.
Theoretically, I don't think you can do anything in WebAssembly that's not possible to do with Javascript.
Re: (Score:1)
> Theoretically, I don't think you can do anything in WebAssembly that's not possible to do with Javascript.
Theoretically you can, by asking JavaScript to do it for you.
Practically, you can do a lot less. At least in the browser. WASI is a whole 'nother can of worms.
Lack of Oracle means less monoculture (Score:2)
WebAssembly will have exactly the same problems as those before it. Because it is the same again.
Flash, Silverlight, and Java have had much more restrictive copyright and patent license conditions attached to them than WebAssembly will have. This lack of anything resembling the legal department of One Rich American Called Larry Ellison encourages independent reimplementations of WebAssembly, as opposed to a monoculture where every device has the same security holes.
Re: Same old, same old. (Score:2)
"Running" HTML code?? (Score:4, Informative)
Seriously?? Are we at that level of cluelessness, or has the What(TheActualFuck)WG managed to turn HTML from a markup language to a Turing-complete programming language? (I would not put it beyond them, but it would obviously have to be renamed as WebHTML and get one more layer of inner-platform effect).
Do I seriously have to explain to you, what an executable or programming language is??
Re: (Score:3)
I guess you missed the whole Javascript thing?
Web Assembly isn't HTML (Score:2)
Neither Web Assembly nor JavaScript are html.
Web Assembly is like a replacement for JavaScript, but better in specific ways. Mostly it's faster, and you can write in any of several front-end languages and then distribute it as Web Assembly, rather than being forced to write in JavaScript I order for your code to run in a browser.
Re: (Score:2)
People already write (generate) the "javascript" in whatever language their web framework is in.
If you thought people were forced to write javascript in javascript, your last knowledge update in this field was probably before about 2006.
Re: (Score:1)
Re: (Score:2)
HTML5+CSS3 are turing complete
Re: (Score:2)
In a weird sense, yes.
In a usable way, no.
No one is writing a C++ compiler in HTML/CSS ... and I'm pretty sure you can't: lack of access to the file system ... so: not really turing complete in any sense that matters.
Re: (Score:2)
Having a standard doesn't imply that you're required to use it.
The same standards body may issue multiple different standards, covering different technologies.
I hope that answers your questions.
Re: (Score:2)
What(TheActualFuck)WG managed to turn HTML from a markup language to a Turing-complete programming language?
Do you include CSS with that? If lie most people you say HTML as a shorthand for HTML+CSS, then the answer is yes, it is in fact Turing complete.
Re: (Score:2)
Re: (Score:2)
I'm intrigued, do you have a link to something demonstrating HTML+CSS emulating a Turing machine?
Sure!
https://en.wikipedia.org/wiki/... [wikipedia.org]
Neither appears to have anything resembling a modifiable state, so I'm struggling, but I know both have a lot of gotchas
HTML does have modifiable state, but it's modifiable by CSS, not HTML. And while CSS can't do anything more than set, it can create new HTML and set that based on existing states.
that means it's not completely impossible the creators didn't at least accide
Re: (Score:2)
Re: (Score:2)
Turing complete des not mean: emulate a turing machine.
It means being able to solve every problem a turing machine can solve.
Re: (Score:2)
Re: (Score:2)
If you can find an example of something Turing complete that cannot emulate an arbitrary Turing machine then you'd be the first.
Actually nothing can emulate a "Turing Machine" - you simply don't grasp the concept.
A Turing machine is supposed to have an infinite long band ... that can not be "emulated" ... it is a thought experiment.
So instead of trying to nitpick one out who actually studied that stuff: read the relevant wikipedia articles.
Secure for whom? (Score:3)
WebAssembly ecosystem that is secure by default
Secure for those writing or using it? The first implies DRM (or inability to reverse compile) the second implies end-user safety. Either way, I'm not sure I'm thrilled about another a potential remote-code exploit vector in my browser -- even with the bonus of it being binary (he added sarcastically).
(For the record, I currently have WebAssembly disable in FF and, I think, Chrome.)
Re: (Score:2)
Meh. Client-side Javascript developers realized a long time ago that they needed obfuscators or someone might steal their super cool code. WebAssembly is kind of a standardized one that also standardizes Javascript transpilers.
Oh yeah, it ALSO benefits from the ongoing erosion of the limitations placed on browswer-executed code, but that's not specifically a WebAssembly thing.
Re: (Score:2)
If webassembly is running on the same engine as javascript (I'm guessing that Google and friends made sure to have webassembly similar to V8 bytecode), doesn't it guarantee it will be as secure as javascript iself? I know it's not much, but at least it means that Webassembly won't open new holes that were not already there.
Re: (Score:2)
Don't worry, Google is eagerly opening new holes for Javascript too. Like file system access.
Re: (Score:2)
It actually is not "secure by default" at all. It just has different problems. But, for example, the very old fashioned buffer-overflow used to overwrite neighboring variables works with wasm as well.
Re: (Score:3)
https://webassembly.org/docs/s... [webassembly.org]
"A protected call stack that is invulnerable to buffer overflows in the module heap ensures safe function returns."
Care to give a counter example? I assume that just like the JVM, it's mostly easy to protect memory from invalid writes, as long as you don't mind sacrificing performance.
Re: (Score:3)
I am not talking about a buffer-overflow on the stack. That one they fixed. But that is just one scenario for buffer overflows.
Re: (Score:1)
But, for example, the very old fashioned buffer-overflow used to overwrite neighboring variables works with wasm as well.
Not true.
A buffer overflow may crash the program, but it can't be used to subvert security.
Data, executable content, and the call stack are each separate.
Re: (Score:3)
Re: (Score:2)
Buffers on the heap can also be overflown.
The trick to making this dangerous is to overwrite other heap data so that later on when that other heap data is processed by some other routine that that routine does something it wasnt supposed to do. For instance a filename (a string constant) may be held on the heap and over-written by the buffer overflow. Later on that file gets opened and read or written to. A target filename may be the name of a log file that is o
Re: (Score:2)
In any modern architecture constants are stored in read only pages, so trying to overwrite a constant will result in a segfault.
Re: (Score:2)
Then overwrite some flags. For example, a flag that specifies the permissions of some currently active user.
Re: (Score:2)
Then overwrite some flags. For example, a flag that specifies the permissions of some currently active user.
It doesn't work that way. The browser's internal settings are not accessible from the WebAssembly memory space.
Re: (Score:2)
And that was not what I wrote, that is just your interpretation. Of course this is about overwriting some flag in the software written in web-assembly.
Re: (Score:2)
Of course this is about overwriting some flag in the software written in web-assembly.
If software running in a particular site's instance of the WebAssembly VM wants to overwrite a flag running in the same site's instance of the WebAssembly VM, could you explain why this is an issue?
Re: (Score:2)
It is not the _software_ that wants to overwrite a flag, it is an attacker that makes the software overwrite a flag _despite_ this not being functionality that the application programmer put in there knowingly. Do I really need to explain why effecting a state-change from outside that some software does not expect is a problem? Or do you just believe code running in a sandbox cannot do any damage at all? Remember this code is part of some web-application software and it does communicate with a server-side
Re: (Score:2)
Or do you just believe code running in a sandbox cannot do any damage at all?
Code injected into a particular site's instance of the sandbox can indeed do damage to business functionality to which that sandbox has access. But first off, how does the attacker inject the attacker's code into another website's instance of the sandbox?
Re: (Score:2)
The usual. Possibly also some additional ways. (Sorry, I teach a full-semester course on web-application security. I cannot summarize that in a single /. posting.)
But this is not about code injection. That should be very hard and may be impossible with wasm. It would actually be _very_ welcome if code injection turned out to be impossible. This is "just" about changing variables. That will hopefully make attacks a lot harder, but wasm does still not manage to be "secure by default" and it is important to re
Re: (Score:2)
Two web assembly programs running in two different sand boxes can not switch flags in the other one nor outside of the sandbox.
Except: the sandbox/browser has a serious bug. Actually a chain of bugs.
Re: (Score:2)
Ah, yes? And how is that relevant?
Re: (Score:2)
It is relevant while you always construct a scenarios that are impossible if the sandbox has no bugs.
Re: (Score:2)
Please get some basic knowledge about application security. At the moment, you are clueless. Not my responsibility to fix that.
Re: (Score:2)
And you perhaps should get a clue about sandboxes, or virtual machines.
You claim WASM is harmful, put the attack vectors are only the same ones you have on a real PC/OS. There is no difference.
Unless your OS or your browser is so buggy that the sandboxes are not sandboxes ... and that has nothing to do with any WASM or whatever ...
What is next? Virtual machines are a problem because one of them can try to find an open port and figure what buggy software is behind it and try to send data that leads to a buff
Re: (Score:3)
Of course it can be used to subvert security if the code has a respective vulnerability.
Since apparently some people do not know what a buffer overflow is, here is an introductory example (C-like notation):
struct example {
char buffer [1];
char security_critical_flag;
}
Overwrite buffer, get control of the flag. Set flag to insecure value. There. Wasm does nothing to prevent that and it cannot.
The only thing why buffer overflow on the stack with code injection became
Re: (Score:2)
If all array accesses are bounds checked (as they are in Java), you can prevent this kind of buffer overrun. Some instruction sets (e.g. ARM ThumbEE and Hyperstone) have features specifically aimed at helping implement all these bounds checks since you're doing so many of them.
(It's funny how instruction sets have features that tie in with the programming languages du jour. SPARC has tagged arithmetic instructions to help implement LISP and Forth, i386 and M68k gained various addressing modes for accessin
Re: (Score:3)
This is _not_ a Java replacement. This is an _assembler_ replacement or rather assembler for a specific stack-machine that transfers well to most modern architectures. The whole point of this thing is to compile a high-level language to it.
Of course, you can compile bounds checks in if a specific compiler that can produce wasm code lets you do that, but you have to accept a performance hit which can get pretty serious.You can even do the bounds-checks in your code. But the whole point of wasm is to have a h
Re: (Score:2)
Wasm does nothing to prevent that and it cannot. ...
Of course it can.
You simply put range checking code around array access
Sorry, you are completely off with your complaints. Why not reading the specs of WASM ... or what kind of code compilers generate.
And how actually do you want to sneak code in, that overwrites the buffer? That can only happen if the original program has a buffer overflow. That is called: a bug. And not a security issue.
Re: (Score:2)
or inability to reverse compile
Ability to decompile is not a security hole.
A false belief that any code can't be decompiled is the security hole.
WebAssembly is an open standard and does not rely on "security through obscurity".
Re: (Score:3)
WebAssembly joins JavaScript as being disabled by default.
Re: (Score:2)
WebAssembly joins JavaScript as being disabled by default.
This raises the question: What should the developer of a web application have to do to convince a reasonable user to enable JavaScript or WebAssembly for that application? Offer a downloadable native application for the wrong OS and say "Users of other devices can use our web app instead"?
Re: (Score:2)
What should the developer of a web application have to do to convince a reasonable user to enable JavaScript or WebAssembly for that application?
The developer merely needs to offer Dancing Bunnies and 99% of people will disable everything necessary.
Re: (Score:2)
What should the developer of a web application have to do to convince a reasonable user to enable JavaScript or WebAssembly for that application?
The developer shouldn't load code from 20+ other domains. Nothing erodes my trust in a webpage when I see it fetching javascript from Google and Facebook and Amazon and Cloudflare and Microsoft and a dozen others.
Re: (Score:2)
As I understand your comment, you want to allow-by-default any JavaScript or WebAssembly code from the same registrable domain name, but block-by-default any JavaScript or WebAssembly code from a different registrable domain name. (Use the Public Suffix list to define a "registrable domain name".) Am I right?
What replacement for Google Maps?
And what replacement for delegating login to an identity provider (e.g. "Sign in with Google", "Sign in with GitHub", "Sign in with Twitter")? Not allowing users to use
Re: (Score:1)
WebAsm uses the same APIs as JavaScript, so any security issues will affect both. As such it's no better or worse than JavaScript.
"Obfuscation"? Seriously? (Score:2)
What level of incompetency are we talking about here? Anybody competent to do software forensics is not really hampered by having to use a decompiler or reading (smaller) fragments directly in assembler. This is just the same as with any other compiled application.
What about those APIs, btw? (Score:5, Interesting)
Without IO, WASM is pretty much useless. You still have to use JS, and can only use it by calling functions from JS.
Or you have to write yourself JS-based a wrapper to import the foreign APIs...
It only becomes interesting, when you can completely ditch JS.
Before that, it is indeed only good for criminal obfuscation. (Like crypto mining, keeping the source closed, DRM, etc.)
Extend LibreJS to cover WASM (Score:2)
Before [WebAssembly can talk to the DOM without a JS shim], it is indeed only good for criminal obfuscation. (Like crypto mining, keeping the source closed, DRM, etc.)
Minimized or obfuscated JS code is the same way. I guess the LibreJS extension for Firefox [gnu.org], which currently blocks execution of minimized, obfuscated, or nonfreely licensed JS code, could be extended to block execution of WebAssembly that isn't marked with a machine-readable link to source code under a free software license.
Re: (Score:2)
WASI is the answer to those questions.
a WebAssembly ecosystem that is secure by default (Score:2)
Re: (Score:3, Funny)
Who are they trying to fool?
The most common answer to that question is "themselves".