5

I'm excited about the prospects of web-assembly for the future, but I'm curious if this will have the same security ramifications of Java Applets.

What are some of the reasons why web assembly is expected to be more secure than Java Applets? (Isn't a sandboxed JVM in the browser similar to how web assembly might work?)

Tom Hawtin - tackline
  • 284
  • 2
  • 11
JacKeown
  • 153
  • 4
  • This link provides some of the answers you are looking for: https://github.com/stevespringett/disable-webassembly – pcalkins Jan 05 '21 at 22:38
  • Interestingly, browser WASM support enables some code execution primitives for use with conventional browser exploits (e.g. against the Javascript engine), even when WASM code isn't used. – multithr3at3d Jan 06 '21 at 00:03
  • I don't think anyone thinks it will be more secure than Java Applets or Flash... it's actually a bigger target because it's already built in to the browsers. On some of them you can't even turn it off. On a side note there are already countless sites who use it to mine digital currencies using your GPU power... – pcalkins Jan 06 '21 at 00:40
  • Wasm is more like a way to speed up JavaScript than a way to offer more capabilities (if anything, Wasm code has *less* features). This is quite different from applets and Flash which were used to do stuff that you couldn't do with JS. Also, Wasm designers had the advantage of not being first – they could learn from the mistakes of precursor technologies like applets. – amon Jan 06 '21 at 10:16
  • it's actually slower than pure JS at accessing/manipulating the DOM... but it's very fast for graphics... things like animation/charts/etc... – pcalkins Jan 06 '21 at 18:19
  • the stack is supposed to be very well defined and secure against injections or overflows. However it allows code to run in the browser's native C++ context when calling WebGL. (It switches from JS to native... which sounds dangerous, but who knows if it will be. They call it the FFI or foreign function interface... because it switches from one language to another... script to compiled ) – pcalkins Jan 06 '21 at 20:17
  • I guess you could also say that this moves the security concerns from Adobe/Oracle to the browser developers. It will only be as secure as the browser's implementation. They had little to no control over Java or Flash/Shockwave... with WASM it's all in house and they are all coordinating to some degree. (apple,MS, google, mozilla) – pcalkins Jan 06 '21 at 20:24
  • 1
    From an admittedly casual look at WebAssembly, the security situation looks much the same as jsasm rather than Java. Breaching its Object Capability Model, the 1.0 and 1.1 Java security models were essentially doing handwritten runtime deny list checks as if restricting linking to a few methods - a convenience method forwarding a call would break it all. I don't think anyone understands the implications of the Java 2 stack inspection security model. (It provided me with employment for nearly a decade.) – Tom Hawtin - tackline Jan 09 '21 at 02:21

1 Answers1

3

Java applets attempted to lock down a privileged standard library from within the process.

APIs like serialization and URLConnection were intended to work in both a full access mode (Java out of the sandbox) and untrusted mode (applets, web start). Privileges were determined by checking the caller’s class loader. This created an attack vector for gadgets: stringing together a sequence of API calls to trick a privileged Java class (say JEditorPane) into performing a privileged action on behalf of an unprivileged class.

It didn't work because the boundaries and responsibilities were unclear. Why was JEditorPane responsible for enforcing URLConnections security rules, only because it used the URLConnection APIs?!

My understanding is that WASM has no complex standard library that needs to work in both privileged and unprivileged mode. Avoiding that design mistake doesn't guarantee WASM security, but it makes it much easier to implement correctly.

Jesse Wilson
  • 196
  • 3