4 ms·

Alternate title: We Learned Nothing About Security From Applets

by cbsmith 6y ago

dcow 6y ago
Were applets sandboxed?
- teknopurge 6y ago
  yes.
  - tadfisher 6y ago
    Optionally.
  - flohofwoe 6y ago
    Not really, a Java applet could load and call into native DLLs, and once you're in native code, you can do pretty much anything on Windows.
    - cbsmith 6y ago
      The security model for Java did not include calling native DLLs. That was something that Microsoft added, essentially tossing away the security model in the interest of trying to create a proprietary advantage for Windows in a Java world.
- smolder 6y ago
  I don't think it was a very effective sandbox at the time Java applets were being used, meaning there were bugs and other glaring security issues. Wasm has the same sandboxing as javascript, which is pretty well worn in and not slow for the user (partly because of faster hardware now). It's not simply a repeat of java in the browser, or the RCE exploit that was flash.
flohofwoe 6y ago
No, it's a completely different topic. Java applets were "unsafe by design" in that they allowed to escape the sandbox (even as a feature via calling out into native DLLs). This paper is only about messing up the WASM heap, which might cause the WASM application to crash, but this doesn't cause damage outside the sandbox.
- cbsmith 6y ago
  > Java applets were "unsafe by design" in that they allowed to escape the sandbox (even as a feature via calling out into native DLLs). The design of the Java applet security model did not include being able to escape the sandbox. That was something Microsoft did that deliberately broke the security model. The closest thing Java applets had to "escape the sandbox" was popping up a new window, and even that involved presenting the user with a warning that the window belonged to the applet.
deleted 6y ago
[deleted]
daniellehmann 6y ago
I don't think that's a fair assessment, and it is also not fair to the designers of WebAssembly. They certainly have spent a lot of thoughts on protecting the host (e.g., browser, underlying OS) from _malicious_ WebAssembly code. This is what we call "host security" in the introduction of the paper. Modulo implementation bugs (which is orthogonal to the design of the language), WebAssembly applications cannot break out of the sandbox more than arbitrary JavaScript already can. However, what we look at in the paper is "binary security", i.e., whether _vulnerable_ WebAssembly binaries can be exploited by malicious _inputs_ themselves. Our paper says: Yes, and in some cases those write primitives are more easily obtainable and more powerful than in native programs. (Example: stack-based buffer overflows can overwrite into the heap; string literals are not truly constant, but can be overwritten.)
- cbsmith 6y ago
  > They certainly have spent a lot of thoughts on protecting the host (e.g., browser, underlying OS) from _malicious_ WebAssembly code. You say that like the Java Virtual Machine designers didn't do the same thing. > Modulo implementation bugs (which is orthogonal to the design of the language), WebAssembly applications cannot break out of the sandbox more than arbitrary JavaScript already can. That has a very familiar sound to it. ;-) > However, what we look at in the paper is "binary security", i.e., whether _vulnerable_ WebAssembly binaries can be exploited by malicious _inputs_ themselves. Our paper says: Yes, and in some cases those write primitives are more easily obtainable and more powerful than in native programs. (Example: stack-based buffer overflows can overwrite into the heap; string literals are not truly constant, but can be overwritten.) I think you've highlighted an important subtlety here for sure. Would you say that Java applets were similarly vulnerable?

Alternate title: We Learned Nothing About Security From Applets

dcow 6y ago

Were applets sandboxed?

teknopurge 6y ago
yes.
- tadfisher 6y ago
  Optionally.
- flohofwoe 6y ago
  Not really, a Java applet could load and call into native DLLs, and once you're in native code, you can do pretty much anything on Windows.
  - cbsmith 6y ago
    The security model for Java did not include calling native DLLs. That was something that Microsoft added, essentially tossing away the security model in the interest of trying to create a proprietary advantage for Windows in a Java world.
smolder 6y ago
I don't think it was a very effective sandbox at the time Java applets were being used, meaning there were bugs and other glaring security issues. Wasm has the same sandboxing as javascript, which is pretty well worn in and not slow for the user (partly because of faster hardware now). It's not simply a repeat of java in the browser, or the RCE exploit that was flash.

flohofwoe 6y ago

No, it's a completely different topic. Java applets were "unsafe by design" in that they allowed to escape the sandbox (even as a feature via calling out into native DLLs). This paper is only about messing up the WASM heap, which might cause the WASM application to crash, but this doesn't cause damage outside the sandbox.

cbsmith 6y ago
> Java applets were "unsafe by design" in that they allowed to escape the sandbox (even as a feature via calling out into native DLLs). The design of the Java applet security model did not include being able to escape the sandbox. That was something Microsoft did that deliberately broke the security model. The closest thing Java applets had to "escape the sandbox" was popping up a new window, and even that involved presenting the user with a warning that the window belonged to the applet.

deleted 6y ago

[deleted]

daniellehmann 6y ago

I don't think that's a fair assessment, and it is also not fair to the designers of WebAssembly. They certainly have spent a lot of thoughts on protecting the host (e.g., browser, underlying OS) from _malicious_ WebAssembly code. This is what we call "host security" in the introduction of the paper. Modulo implementation bugs (which is orthogonal to the design of the language), WebAssembly applications cannot break out of the sandbox more than arbitrary JavaScript already can. However, what we look at in the paper is "binary security", i.e., whether _vulnerable_ WebAssembly binaries can be exploited by malicious _inputs_ themselves. Our paper says: Yes, and in some cases those write primitives are more easily obtainable and more powerful than in native programs. (Example: stack-based buffer overflows can overwrite into the heap; string literals are not truly constant, but can be overwritten.)

cbsmith 6y ago
> They certainly have spent a lot of thoughts on protecting the host (e.g., browser, underlying OS) from _malicious_ WebAssembly code. You say that like the Java Virtual Machine designers didn't do the same thing. > Modulo implementation bugs (which is orthogonal to the design of the language), WebAssembly applications cannot break out of the sandbox more than arbitrary JavaScript already can. That has a very familiar sound to it. ;-) > However, what we look at in the paper is "binary security", i.e., whether _vulnerable_ WebAssembly binaries can be exploited by malicious _inputs_ themselves. Our paper says: Yes, and in some cases those write primitives are more easily obtainable and more powerful than in native programs. (Example: stack-based buffer overflows can overwrite into the heap; string literals are not truly constant, but can be overwritten.) I think you've highlighted an important subtlety here for sure. Would you say that Java applets were similarly vulnerable?