The general point that this article makes is true--C and C++ are still unsafe, even if you execute them in a VM--but there are some very important caveats to note:<p>* ROP should be impossible in Web Assembly, because the call stack is a separate stack, inaccessible from the heap and effectively invisible to the program.<p>* For the same reason, classic buffer overflow attacks involving attacker-supplied machine code are impossible. In addition, Web Assembly bytecode is never mapped into the heap, so attackers cannot inject shellcode via the usual methods.<p>* Mmap functionality is proposed for the future [1], which would allow for the implementation of guard pages. (Guard pages are fairly weak defenses anyway...)<p>I'm sure that it's <i>possible</i> to attack a Web Assembly program's control flow by overwriting vtables and function pointers and taking advantage of the resulting type confusion. But it's significantly more difficult than it is in native code.<p>[1]: <a href="https://github.com/WebAssembly/design/blob/master/FutureFeatures.md" rel="nofollow">https://github.com/WebAssembly/design/blob/master/FutureFeat...</a>
Making unsafe languages safe is not a design goal of WebAssembly. The author seems to believe that WebAssembly should provide many things that are the responsibility of the operating system and standard c library.<p>I do not believe that is a good way of thinking about webassembly. It shouldn't be thought of as an operating system target (like Windows, Linux, or Mac); it should be thought of as an architecture target (like Arm vs x86). What the author wants is an operating system and runtime, which you can write for (and standardize on) web assembly and then load your program into it.
> <i>Technically, this can be implemented already. However, for successful adoption, a standard interface has to be defined.</i><p>This is literally the opposite of how the web works. The web is based on the Extensible Web Manifesto[0], where <i>first</i> we come to a consensus and see widespread adoption, and <i>then</i> we make a standard that reflects that consensus.<p>> <i>We have a fantastic and highly secure execution environment from a host perspective. But from the guest perspective, that very same environment looks like MS-DOS, where memory is a giant playground with no rules.</i><p>Well, yeah. Add me to the list of people who are just kind of confused about why fixing C's problems is the responsibility of the browser, and why people thought that it was ever a priority for WASM. WASM is a VM-like isolation chamber for low-level code. It's not designed to make your code safe, it's designed to protect the host environment from unsafe code.<p>I've seen multiple people make the argument that manually laying out memory in WASM is a design flaw rather than one of the biggest points of the entire implementation. Manually laying out memory with close to zero restrictions or paradigms or safeguards is the thing that makes WASM good.<p>I feel like I missed something, I don't know where people got this idea that WASM was trying to be a higher level tool. It's an extremely low-level language-agnostic compile target for both safe and <i>unsafe</i> languages, and languages that care about safety should add their own safeguards as they see fit.<p>[0]: <a href="https://github.com/extensibleweb/manifesto" rel="nofollow">https://github.com/extensibleweb/manifesto</a>
It is worse than the title says: a key tool for trapping corrupted process state, null pointer segfault, is turned off in WebAssembly targets.<p>The second most common source of process corruption, integer overflow, usually ignored in native targets because direct memory corruption is so much worse, is also adopted into WebAssembly wholesale.<p>This is all overwhelmingly worse than in the native case, because we make some effort to run only trustworthy native code, but browsers actively solicit unknown code from known-hostile sources--most particularly, web ads.<p>The existence of safe-ish languages doesn't help, because there is no incentive to deploy them in user-hostile code fragments.
I'm not sure the NULL pointer access being allowed point is valid.<p>The C standard allows for the NULL pointer to be numerically any value, not just 0, and on some architectures in isn't 0. So I would hope C compilers targeting wasm would just use a different value for the NULL pointer, eg 0x8000000000000000 not 0.<p>Whether they actually do or not I don't know, but it isn't an architectural failing of wasm.
> there would be clear benefits in also delegating basic dynamic memory management to the host.<p>It would be quite hard to spec malloc/free into the Web platform, because of the necessary detail: the behavior of that malloc/free pair would need to be identical (same pointers returned from malloc) in all browsers, for every possible sequence of allocations and deallocations. GC is actually easier to spec since so much of the underlying details are unobservable.<p>It's not impossible in theory, but it seems like it would mandate all browsers use the exact same allocator implementation (say, dlmalloc version x.y.z). In addition, this would not allow optimization over time, again, unlike GC.<p>In the non-browser case, server-side implementations may not need to worry about specs, so more options may be open there.
C is unsafe because it comes with no memory protections. In an environment like a typical operating system (depending on the OS of course), there's a chance it will escape its sandbox. This risk does not exist in wasm. You can write the most atrociously misguided C ever and run it in wasm and know for sure that it will never do anything worse than corrupt its own program state.<p>You get similar benefits by using a decent OS and/or by putting the untrustworthy code in e.g. a docker container. It's still code that can't be trusted but at least you are setting some hard boundaries that have no easy/known ways of being bypassed.<p>However, it would still be bad if the program gets compromised. If, say, you are handling some credit card details and are using some C code to do that and it gets compromised, all of the interesting stuff (i.e. the credit card details) would be inside those boundaries. This is why using C to do that is not a great idea.<p>This is a concept that is often misunderstood by people: most of the interesting stuff (from a hacker point of view) happens inside the sandbox. This is where you access and handle sensitive data and access protected resources (e.g. a third party website). Many attacks use relatively low tech mechanisms such as script injection, man in the middle attacks, social engineering, etc.<p>Wasm indeed does nothing to protect against that. If you are handling user input in any way, that is potentially a way for hackers to inject code in your sandbox. If that sandbox has access to or control over anything interesting, that just got compromised. If you are using a language that is notorious for its decades long history of input validation mechanisms getting compromised (cough C cough), that means you can't trust input validation to function properly even inside a wasm container.<p>This is exactly how many browser attacks work. They don't install viruses on your machine or whatever but they simply trick you into revealing your credentials, visiting some evil website, or entering your credit card. A bit of injected javascript or a redirect is all that this takes. Any injected code never leaves the sandbox; it doesn't have to.
There is also another blog post (link to white paper inside) that talks about different memory safety issues with WebAssembly if using a memory-unsafe language: <a href="https://www.forcepoint.com/blog/security-labs/new-whitepaper-memory-safety-old-vulnerabilities-become-new-webassembly" rel="nofollow">https://www.forcepoint.com/blog/security-labs/new-whitepaper...</a>
> First, hosts have no visibility on how memory is being managed within a guest. Want to diagnose memory leaks? Good luck with that.<p>Is that really true? I think we can implement a memory allocator done by hosts. By using "import" feature of WASM, a guest could implement a memory allocator that imports functions from the host that ask the host to look through the gest's memory directly (it is possible in JS code) and then allocate one. Maybe it will be slower but it is certainly possible that hosts can know what is happening to the memory in this way.
I love the idea of WebAssembly in the browser, but what's the point of using it as an universal module language everywhere else?<p>We can already run most popular languages pretty much anywhere, and I imagine at better performance than WebAssembly, no?
> Memory is represented as a single linear block<p>iirc you can have multiple instances or modules, each with its own private linear memory, and they can be set up to call each other's exported functions. It's just that current compilers don't use that encapsulation when compiling a single program. Am I wrong about this?<p>(I haven't used WebAssembly, only read about it some time ago. But here's a link in support: <a href="https://groups.google.com/forum/#!topic/e-lang/3A6zYWF6u5E" rel="nofollow">https://groups.google.com/forum/#!topic/e-lang/3A6zYWF6u5E</a> "Multiple module instances only share an address space if they explicitly export/import a linear memory, which is just another kind of module-level definition. A module can define its own linear memory and not export it, in which case nobody else can access it.")
this is complete nonsense. A normal c program running on a modern operating system has the mmu control what memory it can access. So, Web assembly's "just a block of memory" is no better - it is the same.
> While escaping the sandbox itself may be difficult to achieve, application security doesn’t benefit from the mitigations commonly found in traditional environments.<p>I feel this the most important point regarding use server-side.