3 ms·

> two WASM programs will be more strongly isolated from one another than two normal programs. Innocent and naive as I am, I feel like this shouldn't be true in

> two WASM programs will be more strongly isolated from one another than two normal programs. Innocent and naive as I am, I feel like this shouldn't be true in a post-spectre world? Surely intra-process isolation is recognized as, at minimum, a difficult problem to solve today? The attack surface of your host, given arbitrary compute powers (which wasm has), is quite significant. It's not to say that intra-process isolation isn't a worthwhile goal, I'd rather see new systems designed with the idea if they can be. I'm just saying I don't know that "unsandboxed but has lots of mitigations" vs "sandboxed but trivially exploitable" is so clearcut.

emn13 5y ago
Spectre seems pretty hard to exploit in practice judging by the almost complete lack of observations in the wild (lots of PoCs you read about, but most won't work with standard mitigations enabled, and I haven't heard of any actual reports of usages beyond PoC toys, but I expect somebody to point to one shortly, of course :-P). Also, spectre is vulnerable to all kinds of mitigations, which vary and are in use, and change - all of which leaves a system vulnerable, but makes the engineering challenge of an exploit greater, and less transferable between systems. And not just the mitigations are varied, the exploit themselves may need to take into account CPU trivia; not every CPU leaks the same way. But even supposing you pull all that off - spectre needs not just some entropy leakage, but also a way to put that entropy in context. Knowing a few random bits in some other processes memory space won't do you much good; you'll need to know something about how that process is working to interpret those bits and target the slow leakage, which is again pretty situational. Finally, you need some way to check for indirect behavior changes, and typically that means timers. Those aren't directly available in WASM, and aren't as easy to replicate using other means as in a normal process; e.g. wasm doesn't even have fully capable shared-memory threads for exactly this reason (there's a proposal, and chrome feature flag, so you can play with it, but that's it); and other tricks to get reliable timers like via SharedArrayBuffer have been tweaked to avoid attack surface. But note: that's the case for WASM, but not for a classic OS program, even one running in a VM. I'm not sure how much of a threat spectre is in practice, but clearly WASM is aware of it and avoiding features that would increase exposure, even very valuable stuff like threads.

emn13 5y ago

Spectre seems pretty hard to exploit in practice judging by the almost complete lack of observations in the wild (lots of PoCs you read about, but most won't work with standard mitigations enabled, and I haven't heard of any actual reports of usages beyond PoC toys, but I expect somebody to point to one shortly, of course :-P). Also, spectre is vulnerable to all kinds of mitigations, which vary and are in use, and change - all of which leaves a system vulnerable, but makes the engineering challenge of an exploit greater, and less transferable between systems. And not just the mitigations are varied, the exploit themselves may need to take into account CPU trivia; not every CPU leaks the same way. But even supposing you pull all that off - spectre needs not just some entropy leakage, but also a way to put that entropy in context. Knowing a few random bits in some other processes memory space won't do you much good; you'll need to know something about how that process is working to interpret those bits and target the slow leakage, which is again pretty situational. Finally, you need some way to check for indirect behavior changes, and typically that means timers. Those aren't directly available in WASM, and aren't as easy to replicate using other means as in a normal process; e.g. wasm doesn't even have fully capable shared-memory threads for exactly this reason (there's a proposal, and chrome feature flag, so you can play with it, but that's it); and other tricks to get reliable timers like via SharedArrayBuffer have been tweaked to avoid attack surface. But note: that's the case for WASM, but not for a classic OS program, even one running in a VM. I'm not sure how much of a threat spectre is in practice, but clearly WASM is aware of it and avoiding features that would increase exposure, even very valuable stuff like threads.