Next-generation "Javascript" will be binary code

[barbaz]

http://arstechnica.com/information-tech ... bassembly/
Scary
I really hope this won't mean that our browsers are going to start downloading binary code and running it straight away
At least they should kill that aspect of this before it hits any level of production; let us, the end users, retain the ability to see what a website is doing on/to *our* computers.

(All the more reason to use NoScript, but still...)


https://github.com/WebAssembly/design

[Thrawn]

Well, actually I can see certain advantages of this.

Websites can already minify/obfuscate code to make it effectively unreadable. Bytecode may add an extra step, to convert it to asm.js, but it sounds like there will already be standard polyfills to do the job, so it may not be a big deal. Maybe such a decompilation could even be integrated into the Web Developer tools. So there won't necessarily be more obscurity.

Actually, bytecode should be somewhat easier (and certainly faster) to parse, so it might be more feasible for tools like NoScript (or other security software) to make a good guess at the intent of a piece of WASM. And it should be a smaller download.

What if it were possible for NoScript to automatically detect and allow snippets of WASM that are found to perform only "safe" operations like folding/unfolding menus? That would be a big usability win.

[barbaz]

There's also a security downside to this - don't attackers have significantly more room to play in binary code vs. text code compiled by the victims' browsers? I mean look at the security history of .NET and Java, which that article compares WebAssembly to!

Plus any bug in the browser's wasm parser/executor could allow for far more potential for damage, e.g. if arbitrary code execution is accidentally permitted, this is arbitrary *byte*code, which can theoretically run anywhere on the OS, not just in the browser like malicious JS (right? am I making any sense there?)

Bytecode may add an extra step, to convert it to asm.js, but it sounds like there will already be standard polyfills to do the job, so it may not be a big deal. Maybe such a decompilation could even be integrated into the Web Developer tools. So there won't necessarily be more obscurity.

Assuming that decompilation will always possible for any runnable wasm bytecode...

Actually, bytecode should be somewhat easier (and certainly faster) to parse, so it might be more feasible for tools like NoScript (or other security software) to make a good guess at the intent of a piece of WASM. And it should be a smaller download.

What if it were possible for NoScript to automatically detect and allow snippets of WASM that are found to perform only "safe" operations like folding/unfolding menus? That would be a big usability win.

Yeah, that would be awesome, but I'm pretty sure that tool won't be NoScript

[Thrawn]

There's also a security downside to this - don't attackers have significantly more room to play in binary code vs. text code compiled by the victims' browsers? I mean look at the security history of .NET and Java, which that article compares WebAssembly to!...
Plus any bug in the browser's wasm parser/executor could allow for far more potential for damage, e.g. if arbitrary code execution is accidentally permitted, this is arbitrary *byte*code, which can theoretically run anywhere on the OS, not just in the browser like malicious JS (right? am I making any sense there?)

Actually, I think you'll find that if it can break out of the sandbox into chrome context, then JavaScript is just as dangerous.

The danger of eg Adobe Reader, or Flash, is not the use of binary per se, but the fact that their sandboxes are much less robust than the JavaScript sandbox. Conceptually, they are programs written in native code, executing a security-controlled subset of instructions in some other language - and so is Firefox when it runs JavaScript. Find a vulnerable function that lets you escape the security controls, and you can take over the native code. It doesn't matter, at that point, whether the controlled code was interpreted or compiled.

Assuming that decompilation will always possible for any runnable wasm bytecode...

I would have thought that anything that cannot be decompiled probably cannot be executed. You can always turn machine instructions back into mnemonics at the very least. The result may be ugly, but so is minified JavaScript...

[barbaz]

Actually, I think you'll find that if it can break out of the sandbox into chrome context, then JavaScript is just as dangerous.

Yes but that still requires the browser as a medium, to run the code. Are you saying that code which won't need the browser as a medium (which the right kind of binary code won't) can't do more damage than JavaScript that "accidentally" gains chrome privileges?

I would have thought that anything that cannot be decompiled probably cannot be executed. You can always turn machine instructions back into mnemonics at the very least. The result may be ugly, but so is minified JavaScript...

Well, I can think of a few cases:
1) DRM encryption of sorts applied to the compiled code, or a DRM lock (if the spec ends up allowing for this and all browswer vendors comply.. I really hope that doesn't happen though)
2) Something like this? viewtopic.php?f=19&t=18581

But in any case, can a "prettifyer" do enough to make it even as human readable as prettifyed minified JS?

(And I'm pretty sure I remember trying to decompile Java code that executed fine, and it wouldn't fully decompile into something human-readable enough... I can't remember what it was or what I was trying to get out of it though.)

[Thrawn]

Are you saying that code which won't need the browser as a medium (which the right kind of binary code won't) can't do more damage than JavaScript that "accidentally" gains chrome privileges?

They're not talking about native code; they're talking about intermediate code, like Java bytecode. Compiled up to a point, then interpreted.

Yes, native code is more dangerous, but binary != native. You can't have a browser running arbitrary untrusted native code; that's complete system takeover as soon as you visit a web page. It *has* to be interpreted in order to apply any kind of sandboxing to it.

I would have thought that anything that cannot be decompiled probably cannot be executed. You can always turn machine instructions back into mnemonics at the very least. The result may be ugly, but so is minified JavaScript...

Well, I can think of a few cases:
1) DRM encryption of sorts applied to the compiled code, or a DRM lock (if the spec ends up allowing for this and all browser vendors comply.. I really hope that doesn't happen though)

Maybe. Theoretically you could also encrypt JavaScript text, though.

2) Something like this? viewtopic.php?f=19&t=18581

Yes, that is more of a concern...although it's basically just obfuscation on steroids.

But in any case, can a "prettifyer" do enough to make it even as human readable as prettifyed minified JS?

If it can be translated directly into asm.js (which is supposed to be the case for the polyfills), then I'd say so.

(And I'm pretty sure I remember trying to decompile Java code that executed fine, and it wouldn't fully decompile into something human-readable enough... I can't remember what it was or what I was trying to get out of it though.)

Well, if you can provide an example, we could look more into that.

[barbaz]

Are you saying that code which won't need the browser as a medium (which the right kind of binary code won't) can't do more damage than JavaScript that "accidentally" gains chrome privileges?

They're not talking about native code; they're talking about intermediate code, like Java bytecode. Compiled up to a point, then interpreted.

Yes, native code is more dangerous, but binary != native. You can't have a browser running arbitrary untrusted native code; that's complete system takeover as soon as you visit a web page. It *has* to be interpreted in order to apply any kind of sandboxing to it.

Ah good, didn't realize there was that much of a difference.

[Thrawn]

That's basically the downside of binary plugins: the plugins themselves are native code. The documents/objects that they read (eg PDFs, Flash) are essentially an interpreted language, but if someone finds a way to tamper with the object and make the plugin misbehave, then they've reached native code and it's game over (barring defences like AppArmor).

PDF.js has the advantage that even if the PDF breaks out into the reader, then the reader itself is interpreted code, so they still have to find a way out of the JavaScript sandbox.

[Tar_Ni]

So what does that mean for the future of an addon like NoScript? Will it still exist in say, 5 years from now?

[barbaz]

So what does that mean for the future of an addon like NoScript? Will it still exist in say, 5 years from now?

I would think that what it could mean (at most) is that NoScript itself becomes written in wasm, either out of necessity or out of Giorgio's choice. Also there will need to be the possibility of surrogates written in wasm, which I think cannot be done in the current architecture of the surrogate system.

I can't really see this having much of an impact to NoScript otherwise - its security model doesn't particularly require that the scripting language in question be JavaScript.

[Thrawn]

I would think that what it could mean (at most) is that NoScript itself becomes written in wasm, either out of necessity or out of Giorgio's choice.

Interesting idea! In theory that would make NoScript a smaller download, but it would also break the current open-source situation, where the XPI is all you need.

I don't think that there are significant performance problems that would be addressed by this; the typical experience is that NoScript makes the web a lot faster. OTOH, maybe ABE would benefit.

Also there will need to be the possibility of surrogates written in wasm, which I think cannot be done in the current architecture of the surrogate system.

I could be wrong, but I suspect that a JavaScript surrogate would be able to replace a real WASM script.

[barbaz]

it would also break the current open-source situation, where the XPI is all you need.

Would it? Giorgio currently packages the ABE.g file which (I think) is not needed by the XPI yet is part of the source code
Plus IIUC there might end up being a choice whether to send a browser pre-compiled wasm or the uncompiled version; if so Giorgio could choose to not have it pre-compiled in the XPI.

I could be wrong, but I suspect that a JavaScript surrogate would be able to replace a real WASM script.

Well that article I linked in the OP makes it sound like JavaScript is actually going to be replaced with wasm, at least on the Web...

[Thrawn]

Giorgio currently packages the ABE.g file which (I think) is not needed by the XPI yet is part of the source code

Well, yes, but then it's not a smaller download, is it? It might be slightly faster, but as mentioned previously, I think that that's not a big issue, except maybe in ABE with big rulesets. So the rework necessary to make NoScript conform with asm.js (and thus be WASM-compatible) wouldn't really be justified, AFAICT.

Well that article I linked in the OP makes it sound like JavaScript is actually going to be replaced with wasm, at least on the Web...

Nah, not possible. How many hundreds of millions of websites use JavaScript? Do we really expect them all to change, with no security imperative? Including sites where maximising performance is not an issue? JavaScript support isn't going away.

[barbaz]

Well, yes, but then it's not a smaller download, is it? It might be slightly faster, but as mentioned previously, I think that that's not a big issue, except maybe in ABE with big rulesets. So the rework necessary to make NoScript conform with asm.js (and thus be WASM-compatible) wouldn't really be justified, AFAICT.

Yeah, I agree that if JS will continue to be supported then NoScript won't need to be ported to wasm.

Nah, not possible. How many hundreds of millions of websites use JavaScript? Do we really expect them all to change, with no security imperative? Including sites where maximising performance is not an issue? JavaScript support isn't going away.

Cool!