4 ms·

So it is cool if you allow an attacker to change the program inside? Not cool. We were doing this back in the 90s.

by eyberg 3y ago

josephg 3y ago
I don’t think wasm supports polymorphic code. I’m pretty sure the code section of a wasm module is not modifiable. It might not even be readable by the module itself. The point of wasm is to allow C code to run unmodified, safely, and with as little performance degradation as possible. Sandboxing will mitigate a huge percentage of security vulnerabilities in wasm modules but C is still C. If you want better memory safety, use wasm with a memory safe language.
- eyberg 3y ago
  The problem as I pointed out in another thread is that it doesn't matter if you are using something like rust. Wasm downgrades rust memory safety "guarantees" because those guarantees are only truly enforced by the operating system.
  - junon 3y ago
    Sorry to be blunt but this is a completely nonsense comment that severely misunderstands how applications, memory, Rust and operating systems work together.
  - slimsag 3y ago
    It's actually the hardware that enforces such guarantees. The OS could have bugs, like the WASM program - even if the entire stack is written in Rust from top to bottom. Really the only solution is memory safe hardware, which there is effort going into, e.g. ARM CHERI[0] and ARM MTE [0] https://msrc.microsoft.com/blog/2022/01/an_armful_of_cheris/ https://msrc.microsoft.com/blog/2022/01/an_armful_of_cheris/
    - eyberg 3y ago
      This is one of the few comments here I actually agree with. Totally agree our current architecture is totally broken. It sounds like ARM MTE is coming soonish so excited to see that.
duped 3y ago
> So it is cool if you allow an attacker to change the program inside? The abstract machine behind WASM is a Harvard architecture, so self-modifying code (even accidentally through attacks) is not possible. Memory safety is still a problem for languages that aren't memory safe, but since the program memory is not writeable from the program itself you can't take over control through memory safety bugs. Now whether the program interprets its data in a way that can be made exploitable is a different bug, but one that exists outside what WASM (or any virtual machine) can fix - it does mitigate the consequences however, since every module is isolated and the runtime uses capability-based security to prevent the code from accessing any system resources that it doesn't need.
- pjmlp 3y ago
  It is definitly possible to corrupt data, even if it is not possible to corrupt the stack.
IX-103 3y ago
WASM uses a Harvard architecture, so the instruction memory is separate from data memory. You can't change the program from within the program because you can't write to that address space.

So it is cool if you allow an attacker to change the program inside? Not cool. We were doing this back in the 90s.

by eyberg 3y ago

So it is cool if you allow an attacker to change the program inside? Not cool. We were doing this back in the 90s.

I don’t think wasm supports polymorphic code. I’m pretty sure the code section of a wasm module is not modifiable. It might not even be readable by the module itself. The point of wasm is to allow C code to run unmodified, safely, and with as little performance degradation as possible. Sandboxing will mitigate a huge percentage of security vulnerabilities in wasm modules but C is still C. If you want better memory safety, use wasm with a memory safe language.

eyberg 3y ago
The problem as I pointed out in another thread is that it doesn't matter if you are using something like rust. Wasm downgrades rust memory safety "guarantees" because those guarantees are only truly enforced by the operating system.
- junon 3y ago
  Sorry to be blunt but this is a completely nonsense comment that severely misunderstands how applications, memory, Rust and operating systems work together.
- slimsag 3y ago
  It's actually the hardware that enforces such guarantees. The OS could have bugs, like the WASM program - even if the entire stack is written in Rust from top to bottom. Really the only solution is memory safe hardware, which there is effort going into, e.g. ARM CHERI[0] and ARM MTE [0] https://msrc.microsoft.com/blog/2022/01/an_armful_of_cheris/ https://msrc.microsoft.com/blog/2022/01/an_armful_of_cheris/
  - eyberg 3y ago
    This is one of the few comments here I actually agree with. Totally agree our current architecture is totally broken. It sounds like ARM MTE is coming soonish so excited to see that.

duped 3y ago

> So it is cool if you allow an attacker to change the program inside? The abstract machine behind WASM is a Harvard architecture, so self-modifying code (even accidentally through attacks) is not possible. Memory safety is still a problem for languages that aren't memory safe, but since the program memory is not writeable from the program itself you can't take over control through memory safety bugs. Now whether the program interprets its data in a way that can be made exploitable is a different bug, but one that exists outside what WASM (or any virtual machine) can fix - it does mitigate the consequences however, since every module is isolated and the runtime uses capability-based security to prevent the code from accessing any system resources that it doesn't need.

pjmlp 3y ago
It is definitly possible to corrupt data, even if it is not possible to corrupt the stack.

IX-103 3y ago

WASM uses a Harvard architecture, so the instruction memory is separate from data memory. You can't change the program from within the program because you can't write to that address space.