5 ms·

The browser's WASM runtime is already a safe sandbox. There's really not much point in 'double sandboxing' both on the language and runtime level.

pjmlp 3y ago
If that is the only place Zig is ever going to be used, then no worries, I guess. WebAssembly sandboxes apparently are going to sort out all security issues in modern computing.
cygx 3y ago
In order to be useful, a sandboxed program needs to communicate with the environment (the equivalent of system calls). If you can corrupt internal state, you can control the arguments to those calls, which may have security implications. For example, if you corrupt a program that's allowed to use web sockets, you'll be able to port scan the user's local network.
- flohofwoe 3y ago
  If that actually works in a browser wasm environment then it's also possible from Javascript, which is a memory safe language (eg either the sandbox works or it doesn't, that also includes the external APIs).
  - cygx 3y ago
    Sure. Under that perspective, it's basically a new vector for XSS attacks.
IshKebab 3y ago
You can still have memory safety bugs in WASM. The difference is that they can only do memory unsafe things within the sandbox. That's better than nothing but still not as good as actual memory safety.
- flohofwoe 3y ago
  From a security pov it doesn't make a difference though, the sandbox needs to be able to safely contain untrusted code, no matter if the code is riddled with memory bugs or not.
  - IshKebab 3y ago
    How do you figure? Imagine a server component that runs in wasm (pretty common). Memory safety bugs could easily lead to information leaks and privilege bypass entirely within the wasm sandbox.
    - flohofwoe 3y ago
      The important part is within the wasm sandbox. Don't run multiple components in the same WASM instance because they can't be properly isolated from each other. That's why traditional operating systems have processes that can't access each others memory. WASM instances don't have this sort of "internal isolation", anything running in the same instance can access all memory in that instance, memory safe language or not. Again, language-level safety doesn't matter here. It makes a lot of sense to write the sandbox itself in Rust, but it must not matter whether code running inside the sandbox is written in Rust. If that would be required, the sandbox has already failed.
      - cygx 3y ago
        Again, language-level safety doesn't matter here It very well can: For example, let's assume you have a graphics editor running in the browser that stores files in the cloud. If it uses a vulnerable C library to decode image data, an attacker might be able to play havoc with your files despite the sandbox never technically having been breached. This can be mitigated by either using a safe language, or having the decoder run in an isolated wasm instance. Either way, you have to design your application with these considerations in mind and can't just take arbitrary, potentially vulnerable applications, compile them to wasm and be done with it.

pjmlp 3y ago

If that is the only place Zig is ever going to be used, then no worries, I guess. WebAssembly sandboxes apparently are going to sort out all security issues in modern computing.

cygx 3y ago

In order to be useful, a sandboxed program needs to communicate with the environment (the equivalent of system calls). If you can corrupt internal state, you can control the arguments to those calls, which may have security implications. For example, if you corrupt a program that's allowed to use web sockets, you'll be able to port scan the user's local network.

flohofwoe 3y ago
If that actually works in a browser wasm environment then it's also possible from Javascript, which is a memory safe language (eg either the sandbox works or it doesn't, that also includes the external APIs).
- cygx 3y ago
  Sure. Under that perspective, it's basically a new vector for XSS attacks.

IshKebab 3y ago

You can still have memory safety bugs in WASM. The difference is that they can only do memory unsafe things within the sandbox. That's better than nothing but still not as good as actual memory safety.

flohofwoe 3y ago
From a security pov it doesn't make a difference though, the sandbox needs to be able to safely contain untrusted code, no matter if the code is riddled with memory bugs or not.
- IshKebab 3y ago
  How do you figure? Imagine a server component that runs in wasm (pretty common). Memory safety bugs could easily lead to information leaks and privilege bypass entirely within the wasm sandbox.
  - flohofwoe 3y ago
    The important part is within the wasm sandbox. Don't run multiple components in the same WASM instance because they can't be properly isolated from each other. That's why traditional operating systems have processes that can't access each others memory. WASM instances don't have this sort of "internal isolation", anything running in the same instance can access all memory in that instance, memory safe language or not. Again, language-level safety doesn't matter here. It makes a lot of sense to write the sandbox itself in Rust, but it must not matter whether code running inside the sandbox is written in Rust. If that would be required, the sandbox has already failed.
    - cygx 3y ago
      Again, language-level safety doesn't matter here It very well can: For example, let's assume you have a graphics editor running in the browser that stores files in the cloud. If it uses a vulnerable C library to decode image data, an attacker might be able to play havoc with your files despite the sandbox never technically having been breached. This can be mitigated by either using a safe language, or having the decoder run in an isolated wasm instance. Either way, you have to design your application with these considerations in mind and can't just take arbitrary, potentially vulnerable applications, compile them to wasm and be done with it.