Comment by DyslexicAtheist | Hacker News Reader

Comment by DyslexicAtheist | Hacker News Reader

Parent Full thread

DyslexicAtheist

gee let me think:

1) increases the attack-surface[0] of the browser (arbitrary code execution in victims browser)

2) wasm shares some of the same vulnerability classes from native applications (thanks to code generation frameworks that allows you to spit out wasm in addition to say C - see Nim & others offering generation via llvm backend)

3) cryptographic verification of payloads is still not possible (afaik)

4) binary blobs from untrusted sources which isn't auditable in the way javascript is (raises the bar for security researchers to identify malicious payload, or really just anyone who want's to audit / poke around)

5) thanks to 1+2 wasm shares the same pitfalls as JavaScript when doing crypto in the browser.

6) all of the above works over plain HTTP links (hurray)

7) assumes that security/integrity can be derived from language subsets and a few rules to prevent specific type of behavior[1]

[0] https://i.blackhat.com/us-18/Thu-August-9/us-18-Lukasiewicz-...

[1] https://webassembly.org/docs/security/

[2] https://nvd.nist.gov/vuln/search/results?form_type=Basic&res...

edit: link to current CVE's

Oh sorry, I thought you were comparing it to other alternatives, I didn't realize you meant WASM is worse than not running code at all. Yes, I agree.

Yeah. Like... Markup languages meant to describe things, then leave rendering to the client. It's gonna be fun once our adblockers become useless because the "Web" apps are essentially blobs that do all the presentation for us. Oh and good luck making that barrier free

most adblockers work by blocking network requests to ad domains, there is nothing wasm can do here. Regarding a canvas site the difference is purely in performance.

1. Perhaps, but we already have JavaScript, and WASM has much less access than JavaScript at the moment. It's definitely something to watch as WASM gets more integrated. 2. Sure, it is intended for native-type development in the browser. In fact, the easiest languages to get started with are C, Rust, and Go IMO. 3. If it's being sent over TLS, you know that it hasn't been tampered with in flight, no? So it is functionally equivalent in this regard to JavaScript. 4. Have you tried to audit obfuscated JavaScript? If that's acceptable, you can do the same with the tools provided for WASM. 5. Yup. However, as I mentioned earlier, TLS removes the ability for things to be tampered with in flight, which means you'll need to trust the server (and the browser). Since that's always the case, I'm not sure what you want to see different here. 6. So don't use HTTP and only use HTTPS? Browsers are moving toward making that look more scary to the user, so it's a browser problem, not a WASM one. 7. No, it assumes the sandbox can prevent security issues. The language subset stuff is to help developers write more reliable code. It won't eliminate crashes from faulty code, it'll just make those easier to spot.

Those CVEs mostly look like problems in the sandbox, which will mature as WASM gets used more. Those types of things point to immaturity in implementation, not design AFAICT.

that 4) holds is not so clear to me, being auditable was one of the design goals.

I think perhaps you and the GP are defining auditable slightly differently. There's being able to look into and figure out what the code you wrote is doing because you have source maps or pre-compilation source, and then there's being able to see what third party code that your browser is downloading and running is doing. Given how hard that can be with JavaScript and obfuscation, I imagine an obfuscating compiler for WASM can do quite a bit if you're willing to take a performance hit on the running code. And something tells me that the entities most interested in obfuscating what their code is doing are more often than not likely to not care too much about the CPU and battery life ramifications of making their code less performant.

Note that integrity checking is supported and used in many sites. Given that, using HTTP does not matter. (Of course not for the main page.)

Reply on news.ycombinator.com