6 ms·

I think that's grossly overstating things. I'd put it this way: C compiled for the WebAssembly runtime is more secure than C in a traditional OS context, howe

by emn13 6y ago

I think that's grossly overstating things. I'd put it this way: C compiled for the WebAssembly runtime is more secure than C in a traditional OS context, however, it has fewer defenses available that protect the program against it's own bugs, including those triggered maliciously. That's because the way you're using secure is likely misleading to most people; two WASM programs will be more strongly isolated from one another than two normal programs. The host has better protection from a WASM program than a C program. Those protections are akin to a VMs, but likely better. The protections that are missing aren't irrelevant, but likely less relevant than in an OS context because WASM's I/O is so heavily constrained. Malicious data is still a possibility, but not quite as trivially triggerable as in any other networked program. Similarly, once hacked, those same limitations make the scope for mischief much, much more limited. Sure, there are attacks conceivable against a WASM program that couldn't work when protected by various defenses in depth available to a "normal" OS program, but the reverse is true too - if you will; the scope of bugs is much, much smaller in WASM, but within that limited scope they'll be more easily triggerable. However, since the scope is so limited, I have a hard time believing the net effect is negative in practice.

chubot 6y ago
Yeah that's fair, WASM I/O is basically "opt in", where as the I/O on an normal OS is basically "opt out" (with something like seccomp, or not at all). WASM does follow the principle of least privilege better.
staticassertion 6y ago
> 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.
kllrnohj 5y ago
> That's because the way you're using secure is likely misleading to most people; two WASM programs will be more strongly isolated from one another than two normal programs This is wholly incorrect. Two WASM programs will be at most as isolated as two normal programs, but in practice substantially less so. Spectre being the obvious one that sort of "fully breaks" in-process sandboxing, but lack of hardware enforcement also means you're now more vulnerable to host bugs, too. Regardless it's a question of what is the juicier attack surface. WASM only cares about protecting the host from the embedded code, but it does that essentially by sacrificing the embedded code's own security from the outside world. That is, if A is the WASM host of B, and B can be called by C, then WASM is about protecting A from B at the cost of making B more vulnerable to C. If B is the thing that actually has the juicy data that C wants in the first place, this is a really bad tradeoff. If A is the juicy target, though, then this is a fine tradeoff. So in a browser context where the host is almost always the juicy target, WASM's tradeoffs work. If, however, you're talking about things like using WASM for web server sandboxing instead of docker or a VM, well the web server itself is likely the interesting attack surface rather than the "hypervisor." So that's probably not a good tradeoff to make there.
- emn13 5y ago
  The reason WASM programs are better protected from each other is because they have virtually no means of interop, and far fewer tricky CPU instructions available. Hypothetically, you might see classic OS programs use a sandbox that's as restrictive, but it's not common, and you'd have to compare each sandbox in detail to get an idea about the tradeoffs. By contrast, normal OS programs have all kinds of I/O, including inter-process communication, shared locks, high-res timers, shared memory, files, networking, etc etc etc. Even if those programs are "fairly isolated" by being inside a VM, they still have access to all kinds of low level tools that WASM won;t have that might leak enough entropy to still be less well isolated - and that's kind of necessary and by design, because a VM or container is designed to run largely unmodified binaries, and thus cannot simply omit capabilities legacy programs have - but WASM can, and does. Then there's simply the sheer complexity difference; it's pretty daunting task to have all that be entirely safe. In essence: there's a reason why it's much more common to see e.g. privilege escalation vulnerabilities than WASM sandbox escapes.

by emn13 6y ago

chubot 6y ago

Yeah that's fair, WASM I/O is basically "opt in", where as the I/O on an normal OS is basically "opt out" (with something like seccomp, or not at all). WASM does follow the principle of least privilege better.

staticassertion 6y ago

> 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.

kllrnohj 5y ago

> That's because the way you're using secure is likely misleading to most people; two WASM programs will be more strongly isolated from one another than two normal programs This is wholly incorrect. Two WASM programs will be at most as isolated as two normal programs, but in practice substantially less so. Spectre being the obvious one that sort of "fully breaks" in-process sandboxing, but lack of hardware enforcement also means you're now more vulnerable to host bugs, too. Regardless it's a question of what is the juicier attack surface. WASM only cares about protecting the host from the embedded code, but it does that essentially by sacrificing the embedded code's own security from the outside world. That is, if A is the WASM host of B, and B can be called by C, then WASM is about protecting A from B at the cost of making B more vulnerable to C. If B is the thing that actually has the juicy data that C wants in the first place, this is a really bad tradeoff. If A is the juicy target, though, then this is a fine tradeoff. So in a browser context where the host is almost always the juicy target, WASM's tradeoffs work. If, however, you're talking about things like using WASM for web server sandboxing instead of docker or a VM, well the web server itself is likely the interesting attack surface rather than the "hypervisor." So that's probably not a good tradeoff to make there.

emn13 5y ago
The reason WASM programs are better protected from each other is because they have virtually no means of interop, and far fewer tricky CPU instructions available. Hypothetically, you might see classic OS programs use a sandbox that's as restrictive, but it's not common, and you'd have to compare each sandbox in detail to get an idea about the tradeoffs. By contrast, normal OS programs have all kinds of I/O, including inter-process communication, shared locks, high-res timers, shared memory, files, networking, etc etc etc. Even if those programs are "fairly isolated" by being inside a VM, they still have access to all kinds of low level tools that WASM won;t have that might leak enough entropy to still be less well isolated - and that's kind of necessary and by design, because a VM or container is designed to run largely unmodified binaries, and thus cannot simply omit capabilities legacy programs have - but WASM can, and does. Then there's simply the sheer complexity difference; it's pretty daunting task to have all that be entirely safe. In essence: there's a reason why it's much more common to see e.g. privilege escalation vulnerabilities than WASM sandbox escapes.