4 ms·

Btw, is WASM really more secure? JVM and .NET basically have capability-based security thanks to their OOP design together with bytecode verification: if you ca

by kgeist 2y ago

Btw, is WASM really more secure? JVM and .NET basically have capability-based security thanks to their OOP design together with bytecode verification: if you can't take a reference to an object (say, there's a factory method with a check), you can't access that object in any way (a reference is like an access token). As far as I understand, in WASM memory is a linear blob, so if I compile C++ to WASM, isn't it possible to reference a random segment of memory (say, via an unchecked array index exploit) and then do whatever you want with it (exploit other bugs in the original C++ app). The only benefit is that access to the OS is isolated, but all the other exploits are still possible (and impossible in JVM/.NET). Am I missing something?

lifthrasiir 2y ago
For now, (typical) WASM is indeed more secure than (typical) JVM or .NET bytecodes primarily because external operations with WASM are not yet popular. WASM in this regard has the benefit of decades' worth of hindsight that it can carve its own safe API for interoperation, but otherwise not technically superior or inferior. Given that the current web browser somehow continues to ship and keep such APIs, I think the future WASM with such APIs is also likely to remain safer, but that's by no means guaranteed.
adrian17 2y ago
AFAIK you’re correct. Also see: https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat... „We find that many classic vulnerabilities which, due to common mitigations, are no longer exploitable in native binaries, are completely exposed in WebAssembly. Moreover, WebAssembly enables unique attacks, such as overwriting supposedly constant data or manipulating the heap using a stack overflow.” My understanding is that people talking about wasm being more secure mostly talk about the ability to escape the sandbox or access unintended APIs, not integrity of the app itself.
igrunert 2y ago
When discussing security it's important to keep in mind the threat model. We're mostly concerned with being able to visit a malicious site, and execute wasm from that site without that wasm being able to execute arbitrary code on the host - breaking out of the sandbox in order to execute malware. You say the only benefit is that access to the OS is isolated, but that's the big benefit. Having said that, WebAssembly has some design decisions that make your exploits significantly more difficult in practice. The call stack is a separate stack from WebAssembly memory that's effectively invisible to the running WebAssembly program, so return oriented programming exploits should be impossible. Also WebAssembly executable bytecode is separate from WebAssembly memory, making it impossible to inject bytecode via a buffer overflow + execute it. If you want to generate WebAssembly code at runtime, link it in as a new function, and execute it, you need participation from the host, e.g. https://wingolog.org/archives/2022/08/18/just-in-time-code-generation-within-webassembly https://wingolog.org/archives/2022/08/18/just-in-time-code-g...
- ndiddy 2y ago
  The downside of WASM programs not being able to see the call stack is that it makes it impossible to port software that uses stackful coroutines/fibers/whatever you want to call them to WASM, since that functionality works by switching stacks within the same thread.
nox101 2y ago
yes you're missing something. Java applets and flash outside of any security and they ran the users code in that insecure environment WASM, in broswers, runs entirely inside a secure environment with no access to the system. js->browser->os | +--Flash/java-->os vs wasm->browser->os further. WASM and Js are in their own process with no os acesss. they can't access the os except by rpc to the broswer flash/java tho, ran all user code in the same process with full access to the os
- kaba0 2y ago
  Seems like a trivial thing to fix though, it was a lack of will over an explicit design tradeoff. At Applet’s time there was simply no such API surface to attach to and make useful programs.
  - nox101 2y ago
    it's not a trivial thing to fix. It took apple, Mozilla, and google years to refsctor their broswers to isolate user code in its own process and then effiently ipc all services to other processes. chrome started with that but also started without GPU based graphics and spent 2-3 years adding yet another process make it possible. mozilla and safari took almost 10 years to catch up.

by kgeist 2y ago

lifthrasiir 2y ago

For now, (typical) WASM is indeed more secure than (typical) JVM or .NET bytecodes primarily because external operations with WASM are not yet popular. WASM in this regard has the benefit of decades' worth of hindsight that it can carve its own safe API for interoperation, but otherwise not technically superior or inferior. Given that the current web browser somehow continues to ship and keep such APIs, I think the future WASM with such APIs is also likely to remain safer, but that's by no means guaranteed.

adrian17 2y ago

AFAIK you’re correct. Also see: https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat... „We find that many classic vulnerabilities which, due to common mitigations, are no longer exploitable in native binaries, are completely exposed in WebAssembly. Moreover, WebAssembly enables unique attacks, such as overwriting supposedly constant data or manipulating the heap using a stack overflow.” My understanding is that people talking about wasm being more secure mostly talk about the ability to escape the sandbox or access unintended APIs, not integrity of the app itself.

igrunert 2y ago

When discussing security it's important to keep in mind the threat model. We're mostly concerned with being able to visit a malicious site, and execute wasm from that site without that wasm being able to execute arbitrary code on the host - breaking out of the sandbox in order to execute malware. You say the only benefit is that access to the OS is isolated, but that's the big benefit. Having said that, WebAssembly has some design decisions that make your exploits significantly more difficult in practice. The call stack is a separate stack from WebAssembly memory that's effectively invisible to the running WebAssembly program, so return oriented programming exploits should be impossible. Also WebAssembly executable bytecode is separate from WebAssembly memory, making it impossible to inject bytecode via a buffer overflow + execute it. If you want to generate WebAssembly code at runtime, link it in as a new function, and execute it, you need participation from the host, e.g. https://wingolog.org/archives/2022/08/18/just-in-time-code-generation-within-webassembly https://wingolog.org/archives/2022/08/18/just-in-time-code-g...

ndiddy 2y ago
The downside of WASM programs not being able to see the call stack is that it makes it impossible to port software that uses stackful coroutines/fibers/whatever you want to call them to WASM, since that functionality works by switching stacks within the same thread.

nox101 2y ago

yes you're missing something. Java applets and flash outside of any security and they ran the users code in that insecure environment WASM, in broswers, runs entirely inside a secure environment with no access to the system. js->browser->os | +--Flash/java-->os vs wasm->browser->os further. WASM and Js are in their own process with no os acesss. they can't access the os except by rpc to the broswer flash/java tho, ran all user code in the same process with full access to the os

kaba0 2y ago
Seems like a trivial thing to fix though, it was a lack of will over an explicit design tradeoff. At Applet’s time there was simply no such API surface to attach to and make useful programs.
- nox101 2y ago
  it's not a trivial thing to fix. It took apple, Mozilla, and google years to refsctor their broswers to isolate user code in its own process and then effiently ipc all services to other processes. chrome started with that but also started without GPU based graphics and spent 2-3 years adding yet another process make it possible. mozilla and safari took almost 10 years to catch up.