Hacker News Reader

Comment by pjmlp | Hacker News Reader

With the recompilation back to C I fail to see how RLbox prevents memory corruption due to lack of bounds checking or UB being explored by the optimizer.

View on HN

There is that risk, yes. For wasm2c to be correct it must emit C code without undefined behavior. As best we know it does that properly today, and we've tested and fuzzed it quite a lot, but whenever you use an optimizing C compiler on the output there is no 100% guarantee.

The host application is still C, and the final compilation of the mix of C and sanitized C still relies on the optimizer to be fast, so it might be possible for the untrusted library to reveal UB in the rest of the application. I can see how the whole approach (wasm + taint) would make compromise of the sanitized bits through crafted data harder, but I'm not sure it does enough for guarding against a supply chain compromise of the library.

And I see the safe languages section[1] in the WasmBoxC post; that looks like it would address most of the remaining UB risk, but Firefox will take some time getting there.

[1]: https://kripken.github.io/blog/wasm/2020/07/27/wasmboxc.html...

There's no guarantee even without optimization. Some optimizations exploit UB, but not all "unexpected" code generation in the presence of UB is due to optimization.

Take signed int overflow on addition. On some platforms ADD wraps, on others it traps. Depending on target CPU you'll get very different behavior even for non-optimizing compilers that just emit an ADD instruction!

WASM is just another target, with its own behavior.

WASM is always bounds checked and doesn't have UB. The C code produced by wasm2c should be the same.

WASM doesn't do bounds checking inside linear memory segments, good luck preventing corruption on data structures stored on the same segment.

Unless the produced C code is validated against optimizations across every single compiler version, there are no guarantees of that actually being the case.

> WASM doesn't do bounds checking inside linear memory segments, good luck preventing corruption on data structures stored on the same segment.

Isn't the point that you don't care?

Each untrusted library is compiled to wasm then C then native, they can corrupt their own datastructures but the point is to prevent that corruption from escaping those boundaries, or at least that's how I understand it.

Mostly that's the case, yes. The main benefit of wasm sandboxing in this situation is to keep any exploit of these libraries in the sandbox - no memory corruption outside. That's a big improvement on running the same code outside of a sandbox.

(But in general corruption inside the sandbox is potentially dangerous too. You need to be careful about what you do with data you get from the sandboxed code. RLBox does help in that area as well.)

Just because corruption doesn't escape the sandbox doesn't means it isn't exploitable.

This like attacking microservices, you have a module that exposes a set of interfaces and produces outputs when called with specific APIs.

For the sake of example lets say you have an authentication module that says if a given user id is root.

Now imagine producing a sequence of API calls that it will trigger the side effect of is_root(id) being true for an id that it is a plain user.

No sandbox escape took place, only internal corruption of internal data keeping structures that lead the is_root() to misbehave.

The code implementing is_root is not an untrusted module.

Think of some online banking application written in C++ and compiled to the web. With js, they only have to worry about css exploits and similar. If they use C++, suddenly they also have to worry about all the C++ bugs, too.

they specifically address this in the article; the objective is to be able to treat the component as untrusted code (the same as a website's js) and sanitize/check the component's output (the same as web APIs called by js).

Corruption is not an issue when you assume the corruptee to already be an attacker

Programs running natively on a computer have some security measures in place that wasm binaries lack, while wasm has other security measures in place that native programs lack. Quoting the "Everything Old is New Again: Binary Security of WebAssembly" paper:

> Comparing the exploitability of WebAssembly binaries with native binaries, e.g., on x86, shows that WebAssembly re-enables several formerly defeated attacks because it lacks modern mitigations. One example are stack-based buffer overflows, which are effective again because WebAssembly binaries do not deploy stack canaries. Moreover, we find attacks not possible in this form in native binaries, such as overwriting string literals in supposedly constant memory.

https://news.ycombinator.com/item?id=24216764

https://www.unibw.de/patch/papers/usenixsecurity20-wasm.pdf

Yes but the impact of a wasm buffer overflow is completely different to a C buffer overflow. A C buffer overflow can (sometimes) let you execute arbitrary code. A wasm one will just result in data corruption.

That data corruption may be exploitable (e.g. if it lets you overwrite a password) but those kinds of attacks are much much rarer than the kind that wasm prevents.

Being rarer doesn't make them nonexistent, as the WebAssembly advocacy tends to be around most places.

This blog post explicitly calls out that out:

> the programmer only needs to sanitize any values that come from the sandbox (since they could be maliciously-crafted), a task which RLBox makes easy with a tainting layer.

I don't think I've ever heard any WebAssembly advocates saying that it magically solves all security issues.

Reply on news.ycombinator.com