Hacker News Reader

Comment by flohofwoe | Hacker News Reader

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.

View on HN

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.

The worst that can happen is that the image tool saves back a corrupted image. But that's also possible with a buggy (but memory safe) Rust image loader/saver, memory safety doesn't automatically fix all classes of bugs.

Apart from that it would be quite a feat to use internal memory corruption for anything useful in WASM, because both the code and callstack live outside the sandbox and are not accessible from within (e.g. tricks like return-oriented programming are not possible in WASM.

https://www.youtube.com/watch?v=glL__xjviro&t=450s

Instead of popping up an alert, you could have requested the deletion of all files in the cloud storage.

Thanks for the link, very interesting! But TBF: the 'host program' has to be written in a very specific way to allow that rogue Javascript execution, it's very similar to allowing an SQL injection to happen.

I also wonder why stack canaries wouldn't work on WASM, since the compiler creates stack frames on the data-only stack just the same (but maybe Clang's `-fstack-protector` doesn't work for some reason in WASM, I'll actually need to check that).

You're talking about compartmentalisation which is still just a proposal (wasm component model). You can't use it yet.

Reply on news.ycombinator.com