The Dark Side of WebAssembly (2018) | Hacker News Reader

The Dark Side of WebAssembly (2018)

virusbulletin.com

38 pointswalterbell25 comments

This has to be some of the thinnest gruel I've read in a while. The entire premise of the article is that the "dark side" of WebAssembly is that "security" products can't do string matching against compiled code.

Case 1: People can write scams that "security" products can't block because WebAssembly somewhat obfuscates the code. The comparison to scanning WASM in a "security" product is like opening an executable in a text editor is laughable.

Case 2: People can write website keyloggers in WASM and it will be obfuscated against "security" products. Alternatively the bad guys could just obfuscate plain old JavaScript, or any number of other techniques to exfiltrate data. If people are executing malicious WASM on your website you're already owned.

The only one of their points that has any merit is that WASM implementations increase the attack surface of the browser. This is ostensibly true, as do all new features. Fortunately the major browser vendors have competent engineers dedicated to testing their software for vulnerabilities.

Yeah, I expected it to say WASM somehow makes browsers intrinsically more vulnerable to exploits despite the sandboxing. But this is definitely reaching.

I would also argue that security should not depend on your ability to introspect into code, because whether code is treating data according to the user's expectations isn't something that's going to be statically analyzable.

The interface which consumes the code should be safe.

Furthermore almost any programming language is going to be pretty much impossible to analyse the behaviour of. There are are some pretty fancy theorems about incomputability, but really it's just because you can build a compiler that reads obfuscated byte code.

Forget not being able to use string matching, there are no programs capable of predicting the behaviour of programs without effectively running it in a sandbox.

> The only one of their points that has any merit is that WASM implementations increase the attack surface of the browser. This is ostensibly true, as do all new features.

If things go following to what seems to be the plan, and the JS interpreter is replaced by one that compiles into WASM, it will severy reduce the attack surface. The WASM VM is much simpler than a JS interpreter.

But well, of course, that's a long time in the future. Up to then, you are correct.

I disagree because obfuscated JavaScript would already be suspicious as it is not that widespread as an industry practice. The standard industry practice for JS is minification, not obfuscation; so you can still see what functions are called and any developer can quickly identify if there is a suspicious looking AJAX request to a strange URL.

With WASM, you can't see anything. It's a complete black box. It's a lot easier for a hacker to hide stuff from users. It's easier to sneak in malicious code and it's harder to identify and remove it.

Minification is a form of obfuscation, and a lot of libraries and commonly used scripts are purposely completely unreadable. show_ads.js, for example, is nonsense, so it's not unreasonable for a hacker to sneak into ad code, insert some dubious lines of code that does more or less anything they'd want. There are easy was to mitigate this for sure, but it doesn't seem that WASM makes this point worse. Surely you could just as easily spot an AJAX request from a strange URL while utilising WASM too?

With WASM, you can't see anything. It's a complete black box.

That isn't a problem in itself, as long as the only mechanisms for the black box to interact with anything else are well-defined and properly secured.

Put another way, I shouldn't need to decompile arbitrary WASM code downloaded by some site I visit, as long it's only allowed to do anything through APIs that I'm happy with.

You're definitely right, string inspection of JavaScript is not really a thing, I'm not aware of it being done and it wouldn't be reliable unless you had something that powerful than a regex.

I will say though, that I have seen some products out there today that work by rendering text as pixels on a <canvas>, so that accessibility if you can't read it with your eyes, searchability, discoverability, etc are nonexistent.

This is something WASM could inadvertently encourage a higher percentage of products to use for whatever purpose. Same thing people did with flash.

As others have pointed out, this article is not very convincing. I don't agree with the point that WASM is somehow more suitable for nefarious purposes than obfuscated JavaScript. I suppose that if anything, the execution model of WASM is much simpler than that of JS and it should thus be much easier to analyse.

> This prevents the user from escaping the scam by pressing keys like ESC or the CTRL+ALT+DELETE combination, or others as shown in the table.

The part about CTRL+ALT+DELETE is just nonsense. This key combination is directly handled by the Windows kernel and cannot be captured by a user space application. Hence the "Press CTRL+ALT+DELETE to login" prompt. [1]

[1] https://en.wikipedia.org/wiki/Control-Alt-Delete#Windows

You can make 90% of people afraid of XYZ, if you write a sufficient amount of text "explaining" how dangerous XYZ is.

But arguably Webassembly is also dumb and has no reason to exist, so there's that on top of it being a great way to obfuscate malicious code.

I suggest you take a look at actually obfuscated JavaScript; it's barely any better than WebAssembly.

Running Unreal Engine in the browser, in any browser, is pretty cool. I think there's going to be a lot of interesting use cases for it.

Cool? Maybe if one fetishizes overengineering and abstraction layers.

Calling Webassembly dumb is really dumb. Look at their github repos and consider how much very cleverly done work is there.

Calling it useless in a world where most people are running JS is also weird, but that's more subjective.

Saying that WASM has no reason to exist is going a bit far. Rather than trying to list the reasons, I'm going to refer to the official FAQ: https://webassembly.org/docs/use-cases/

> Better execution for languages and toolkits that are currently cross-compiled to the Web (C/C++, GWT, …).

> Image / video editing.

> Games

> Peer-to-peer applications

> ...

In my view it's trying to create a safe sandbox for things that we previously used unsafe sandboxes (Flash, Java, Silverlight etc.) for. A standard interface for all of these will be much better for everyone.

I look at it the same way I do a new technology on our mission-critical systems. It starts with a tag of 'unsafe' or 'unstable' until it is given time to prove itself out in the real-world.

Sure, we might not get to geek out over the best and latest software and standards, but we're not going to bleed over the leading edge when it fails. I'm happy to give it more time to demonstrate its various modes of failure.

In a year or two, I'll revisit turning javascript.options.wasm back on in FireFox. And if by that time it proves that it is trustworthy and necessary? Yes, I'm quite happy to enable it!

Meh. You can’t use string search to find patterns in wasm files per se. You can look for byte equivalence in functions (or whatever they’re called in wasm.) Thinking of wasm as compiles machine code isn’t quite right (IMO) as it more closely resembles a serialized abstract syntax tree.

I dislike webassembly, but I dislike the direction web is going in general. Everything has to be hidden away from user; you have less and less control over what is happening unless you take active steps rein it in.

OTOH, I really do not understand why such technology is needed. Mom and pop store needs smooth unreal engine to show their virtual store?

Can we at least use that technology for something beneficial long term ( say distributed websites )?

OTOH, I really do not understand why such technology is needed.

One advantage is that it provides a standardised way to escape most of the historical baggage of JS, which in turn means we can use better programming languages for writing web applications and/or develop new ones.

All WebAssembly can do, can be done with Javascript (there are no new capabilities). But WASM can do it a bit faster. It is also easier to convert non-JS code to WASM than to JS.

You can still create websites the way you created them 25 years ago. They will work in all browsers. All the web code (HTML, JS, CSS...) is always visible to the browser and the user, nothing can be hidden (otherwise, the browser would not be able to show a website).

I guess you are complaining about authors putting all HTML code on a singe line, or naming JS variables with one letter. But they could do it 25 years ago, too. It does not mean you have to do it.

> OTOH, I really do not understand why such technology is needed.

Well, let's ask the majority of the W3C Members which are mostly made up of for-profit companies and most develop closed-software. I can tell you that they are going to use WebAssembly for whitebox-cryptography due to its black-box nature of binary code which also introduces it to unwanted DRM features to limit the functions of content of the end-user.

So we have the hype around WASM making it possible to create binary blobs of standardised malware working on every browser rather than creating an open web. Seems like these companies were only cheering this on due to it advancing the state of DRM which we will also win free malware-enabled WASM too.

Great job guys! One step closer to being worse than Flash.

While from a security standpoint, this is kind of silly, I still am not really a fan of just how far off from the source code WASM is. I don't really like minified js either... the gains are pretty minor (so much less than proper tree-shaking) and the only real gain is obfuscation... which is really only a gain for selfishness.

WASM isn't as popular or useful as we hoped it would be at this point, that's the dark side.

Reply on news.ycombinator.com