Hacker News new | past | comments | ask | show | jobs | submit login
[dupe] Everything Old Is New Again: Binary Security of WebAssembly [pdf] (unibw.de)
112 points by xctime 44 days ago | hide | past | favorite | 70 comments

Everything old is new again: binary security of WebAssembly - https://news.ycombinator.com/item?id=24216764 - Aug 2020 (51 comments)

"If a story has not had significant attention in the last year or so, a small number of reposts is ok. Otherwise we bury reposts as duplicates."


I think the best summary of this paper (discussed last year as well [1]) is:

Designers of the WebAssembly spec explicitly chose to scope its goal of a 'secure sandbox' to only include securing the host's memory from the WebAssembly VM. They have succeeded in this goal (modulo implementation deficiencies). However, they left open the question of how a developer might ensure the correctness of their program running in the sandbox. This paper explores the consequences of that original design goal for such a developer, and concludes that all the regular binary exploit mitigations may still be useful for ensuring program correctness.

I made a comment at the time:

> ... Notably, they don't appear to even try to break the WA-host memory barrier, which I actually find to be a validation of the core design goal of WebAssembly: isolate the damage a vulnerable program can inflict to the memory space (and thus also output) of that program. Protect the host from the program, but not the program from itself. Also, maybe don't dump WA output you can't validate directly into DOM.

To which the paper's author replied:

> ... I do agree with you, however, that our findings do not invalidate the overall design of WebAssembly. ... I also think "host security" (which we are not really looking into) is solid, with two qualifications: ...

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

I do not understand the point of this paper. The correctness of the binary is the issue for a compiler, not for the run-time. It mainly discussed mitigations against legacy C code. E.g. new Rust code does not have these issues. Furthermore mitigating issues runtime has a performancy penalty and I do not want my code to be slower because some old C issues from back in the day.

Daniel here, one of the authors.

You are right, some of the issues highlighted in the paper could be solved by compilers targeting WebAssembly. One such mitigation that is (currently) missing are stack canaries. In contrast, stack canaries are typically employed by compilers when targeting native architectures. They also cost performance there (typically single digit percentages), but evidently compiler authors have decided that this cost is worth the added security benefit, since fixing "old C issues" in all legacy code in existence is not realistic.

Note however, that other security issues highlighted in the paper _are_ characteristics of the language, notably linear memory without page protection flags. One consequence of this design is that there is no way of having "truly constant" memory -- everything is always writable. I do think that this is surprising and certainly weaker than virtual memory in native programs, where you _cannot_ overwrite the value of string literals at runtime.

The decision to not (yet) have finer-grained protection for WebAssembly memory pages was in part motivated by the JS API surface in the web embedding. WebAssembly memories are exposed to JS as ArrayBuffers, and optimizing JITs can and do optimize ArrayBuffer access down to naked stores and loads. In addition to the optimized JIT code, ArrayBuffers are used throughout the webstack for moving data into and out of programs (read: Chrome's 6 million lines of code). The entire webstack is not really prepared for read-only ArrayBuffers causing signals underneath.

That said, we always knew a day would come where WebAssembly would get the ability to set more page protections. For non-web embeddings, this is easier, but as of yet, none of the engines I know of have either an API or are really prepared for the implications of this. I am still bullish on eventually getting that capability, though.

Thanks for your paper.

Thanks a lot for the additional background, and also for all the work on WebAssembly. It is a very cool language and having it available with linear memory now is much better than if it were still in the works due to figuring out page protections.

As you said, I just hope page protections can still be added later (somebody needs to specify it, embedders need to be able to implement them, toolchains need to pick it up, etc.).

Maybe memory vulnerabilities inside WebAssembly programs can also be mitigated in other ways that do not require such pervasive changes, e.g., by keeping modules small and compiling each "protection domain" (e.g., library) into its own module, or to have a separate memory. I am not sure about the performance cost of such an approach, though.

Thank you for the clarification!

> The correctness of the binary is the issue for a compiler, not for the run-time .

That is not true. As the paper goes into depth, linear memory, lack of ASLR, and the lack of read-only memory are problematic regardless. The latter is the most important imo.

The point is that C compiled for the WebAssembly runtime is less secure than C in a traditional OS context, because of the lack of defenses on stack, heap, and control flow integrity.

I agree it makes Rust more attractive than C for WebAssembly.

But the original demos for WebAssembly were all in C, not Rust (games like Doom IIRC). The thing that made it attractive in the first place is that you could run existing code, e.g. image processing or machine learning in C/C++.

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.

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

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.

You're essentially arguing that WASM is a better selinux than selinux is.

It isn't.

WASM right now is missing all those things because WASM right now is a toy for moderately accelerating JavaScript. If WASM's usage expands beyond that, those feature limitations will rapidly vanish.

You're talking about some hypothetically fully featured WASM that has all kinds of attack surface it simply doesn't have today. It doesn't even have threads; nor accurate timers, nor shared memory; and those choices aren't by coincidence, they're by design to keep things safe (see e.g. https://github.com/WebAssembly/threads/issues/8).

If indeed webassembly adds features that add attack surface, I sure hope (and fully expect) them to take things like spectre into consideration.

As to SELinux: the issue with securing existing programs is that those use all kinds of existing features; it's quite hard to take away functionality that programs depend on. SELinux simply has a much harder and trickier task than WASM, which never supported almost everything SELinux seeks to control in the first place. It may well be that it's possible to have SELinux enforce WASM-or-greater restrictions and that it would then be "safer" due to other features, but that's a pretty hypothetical scenario - what software would even run in those circumstances?

The comparison seems moot to me; apples to oranges. One is trying to KISS and be safe by simply not having complex features; the other is trying to deal with real, existing programs by restricting stuff they could access but don't need. Those are different use cases.

I explicitly stated I was talking about WASM being used in traditionally native process contexts - like in a serverless/microservices architecture. The first obvious step of someone offering that is to just import libc so existing code can migrate to it.

You seem to be continually focusing exclusively on the current existing extremely limited WASM-in-a-browser usage.

WASM's current limitations aren't intentional, it's because it's not finished & wasn't necessary for the MVP. In fact, it already has some of the things you are claiming it doesn't have - both threads & shared memory are available already in Chrome & Firefox's stable releases ( https://github.com/WebAssembly/threads/blob/master/proposals... & https://webassembly.org/roadmap/ ). Which means it also has accurate timers.

WASM very intentionally allows the host to expose whatever feature set it wants. That's a very core design element. You can't just ignore that and focus on the ~nothing that the "spec" itself delivers & pretend that's by-design. WASM isn't a standalone runtime and isn't trying to be.

Ah, threads got enabled, and quite a while ago. However, not in a way that's spectre sensitive; only in a site-isolation context (https://groups.google.com/a/chromium.org/g/blink-dev/c/_0MEX...).

You state WASM's limitations aren't intentional; they just weren't finished - but being able to use those securely is part of being finished, and they weren't enabled in browsers until they were.

Obviously other hosts may do whatever they want. That's a valid hypothetical, but just as valid a hypothetical is that WASM implements relevant defense in depth features before such poorly sandboxed hosts become commonplace; it's not like they're not aware of the issue (https://webassembly.org/docs/security/). Hypothetically it might be "safer" than SELinux; but... today none of this matters, and the missing features don't appear to be intrinsic. It's not like native programs have had ASLR since day 1 either, right? Or maybe WASM stays in the "highly isolated" niche which is fine too, and would still allow various usages outside the browser too (e.g. for most apps that don't interact with other apps outside of a few carefully controlled primitives).

If people make poor choices about future development, things may end up less secure than they are today: sure.

So, on the one hand I can't dispute what your saying - I just think it's not the best thing to be focused on, because a trivial summary would make it seem like there's a real risk in having WASM as it is today, and that's not the case. We should be very careful in the future, yes, but let's not throw out the baby with the bathwater; wasm's portability and sandboxing in practice today are likely quite useful and more secure (in a browser context) than a native app (outside of a browser context).

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

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.

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.

"secure against what"? Do you mean the script in the webpage running in my browser tab might be attacked by some virus already running on my computer? Or do you mean a virus running inside WebAssembly might attack my computer?

If it's the first one, I dont think i really care.

I think it’s more like: a script running in your browser tab, given some untrusted input (say, an image you import into an editing program) could be compromised by malicious input, such that the script runs malicious code and exfiltrates other data from the app (say, your email address or other private data you used on the page).

That's a definite risk in general.

But worth adding that Wasm by design lets you statically inspect all the things the Wasm can call. If the Wasm receives access to networking, or eval(), etc., then there is a real risk. However, often the Wasm imports and exports are extremely limited and easy to verify for safety.

Section 5.1 gives a good example: an image sharing service that processes images using libpng. This has to be combined with a document.write() of HTML in C, which is realistic.

Someone who controls the image data can perform an XSS, i.e. steal your credentials for the website, or your credit card info if that's stored server-side. That's not as valuable a target as controlling your computer, but it's not nothing, and can be chained.

This is completely realistic as Figma is full blown image editor written in C++ compiled to WebAssembly :)


"Someone who controls the image data" to me that sound like something outside the sandbox manipulating the image data given to the sandbox.

If this is the case it mean there is already a hacker or virus running outside the sandbox which mean I already have bigger problem to worry about :).

No, it means a random user can upload a malicious image and hack the service.

neither, the program might just crash or be buggy. Maybe in some rare cases do malicious things to the programs running in the sandbox.

I agree that the paper's title is somewhat overblown, especially the prefix "Everything Old Is New Again". Specifically, "old" things like all VM runtimes being directly vulnerable to malicious code is not carried over by WA -- to the contrary, WA seems to have captial-S Solved this problem which is certainly an advance.

That said, it does highlight that memory-safe source languages and other program exploit mitigations are still important even in a webassembly sandbox. Personally I wasn't confused about this fact, but it does clarify this point for any that might think that WA == no more security problems in any context.

It's easy to misunderstand this paper. This is not about breaking out of the wasm sandbox. You can't use these vulnerabilities to take over the browser, execute arbitrary code, install malware, etc. This is only about modifying memory inside the sandbox.

By modifying memory you could potentially cause the existing code in a wasm binary to do unexpected and potentially malicious things inside its sandbox. Which can be bad. But no more than that, unless you can chain it with other types of vulnerabilities. And using safe languages for your wasm code helps. The paper also points out that uses of wasm outside the browser, e.g. in node, may not be securely sandboxed.

I hope that wasm people are looking at adding mitigations for some of these attacks. Stack overflow in particular seems like something that can be protected against.

Good summary and clarification. Yes, we do not aim to break out of the (browser) sandbox, and yes the example exploits only use functions that are already imported into the vulnerable WebAssembly module.

However, I would draw a bit more attention to the consequences when memory vulnerabilities in a WebAssembly binary are exploited:

(1) Not every WebAssembly binary is running in a browser or in a sandboxed environment. The language is small, cool, and so more people are trying to use it outside of those "safe" environments. E.g., "serverless" cloud computing, smart contract systems (Ethereum 2.0, EOS.IO), Node.js, standalone VMs, and even Wasm Linux kernel modules. With different hosts and sandboxing models, memory vulnerabilities inside a WebAssembly binary can become dangerous.

(2) Even if an attacker can "only" call every function imported into the binary, it depends on those imported functions how powerful the attack can be. Currently, yes, most WebAssembly modules are relatively small and import little "dangerous" functionality from the host. I believe this will change, once people start using it, e.g, for frontend development -- then you have DOM access in WebAssembly, potentially causing XSS. Or access to network functions. Or when the binary is a multi-megabyte program, containing sensitive data inside its memory.

Sure, the warning is early, but I'd rather fix these issues before they become a common problem in the wild.

Agreed. Wow, Ethereum 2.0 has wasm support? I hope nobody is writing smart contracts in C++...

You should look at what people actually write 'smart contracts' in. It is so bad it seems like a parody of what you would actually want to do.

That's not an accurate summary. You can take over the browser by chaining exploits. Sections 5.1 and 5.2 show two examples.

Needing to chain isn't as bad as a full breakout, but in practice, attackers can and do chain exploits. (pwn2own has some really impressive chains, but those are about breaking out of the sandbox)

If you had written the code in JavaScript, this class of vulnerability would be impossible.

Also remember that WASM doesn't actually improve peak performance over JS. The asm.js subset of JS has the same performance.

WASM does two things 1) it makes performance predictable by ensuring you don't fall off a cliff of the JIT 2) It improves parsing time because it's loading a binary format rather than parsing JS.

e.g. notice that the headline here is about load time, not execution time, which would be more important: https://www.figma.com/blog/webassembly-cut-figmas-load-time-...

> You can take over the browser by chaining exploits. Sections 5.1 and 5.2 show two examples.

5.1 is XSS due to using document.write with a user provided string. That's not taking over the browser and is very much possible from JS (it's basically the prototypical XSS example from well before there was wasm).

5.2 is more serious but in node, not the browser, and is barely a chain (two exploits?). It's a way to get a string to eval() if eval() is available in one of the indirect functions. I think the authors also overstate the benefits of ASLR in that case. If that same code was running natively in a server and exposed to direct user input like that, it's very possible an RCE could be made to work.

These examples are simple by design since they're just demonstrations that it's possible, so more sophisticated attacks are possible, but we also shouldn't over extrapolate from them.

Yeah I wasn't precise enough, I wrote a better summary here: https://news.ycombinator.com/item?id=26996738

tl;dr A bad case is if something like Figma stores your credit card info on the server. If they have a buffer overflow + document.write() of HTML derived from wasm code, the person who controls the image data could steal your credit card info.

This is basically example 5.1; Figma is a huge chunk of C++ compiled to wasm, which may process images from other users.

I disagree with your disagreement. :)

"oh but you can chain exploits" in this context is like if a php server takes POST data, passes it through an arbitrary but guaranteed to terminate "safe" function, and calls eval() on the result -- and then attributes potential vulnerabilities to the function. This seems silly, obviously the problem is the eval() at the end.

At the end of the day, if an attacker needs to chain exploits that's still a safer place to be that if they didn't need to do so. Additionally, how relevant is a link in an exploit chain when it's very likely the same overall effect could be had without using that link? Not very.

And as you say, the examples given are really poor; they're barely exploits, that's more like a really unwise feature - it's hard to imagine situations like this arising in practice by accident without being more easily exploitable without even using WASM in the first place - I mean, if you're processing data in a some way and your interface with that processing code includes stuff like eval, that's just a disaster waiting to happen - as web exploits over the decades have demonstrated again, and again.

You can't take over the browser without chaining to a browser exploit, which is a much higher bar. If you already have a browser exploit I think you are unlikely to need to chain it from a wasm binary.

You can potentially take over the page, but again only if you have vulnerabilities in the JavaScript interfacing with the wasm code. There is only one browser-based example in the paper and the vulnerability is due to using document.write which is always a security no-no.

It's a meaningless point in the chain. Browser security is not intended to be only for running "trusted" or known JavaScript or WebAssembly code and hence competitions like Pwn2Own are perfectly happy to have you navigate to your own page that then runs whatever WASM or JS you want. Nobody requires you to first find an XSS on HN for your exploit because getting someone to load a random page is an extremely low barrier.

"unless you can chain it" Isn't that the GOTO for vulnerabilities these days? Saying "unless" means "when" in reality...

Daniel [1], one of the authors here. Feel free to ask also technical questions, I'll try my best to answer them.

If you don't feel like reading the whole paper, there is also a short (~10 min) video on the conference website [2], where I explain the high-level bits.

[1] https://software-lab.org/people/Daniel_Lehmann.html [2] https://www.usenix.org/conference/usenixsecurity20/presentat...

Great overview. Would it be correct to characterize the fwrite capability as one of the more concerning potential exploits (ie. esp. when combined with other browser vulnerabilities)?


You are referring to the example exploit in section 5.3, right? Please note that this example is for a standalone VM, not inside the browser (where JavaScript programs -- and by extension, WebAssembly modules -- do not have direct access to the filesystem).

Whether that exploit is more or less concerning than the browser and Node.js examples, I think is hard to answer in general without additional qualifications. If the standalone VM uses fine-grained capabilities (e.g., libpreopen) or is sandboxed, then changing the file that is being written to might be possible inside WebAssembly memory but access could be blocked by the VM.

This paper always confuses people. The wasm sandbox is secure, and continues to be. This paper merely states that if you use an insecure language and mess up, then your program can be messed with.

The paper is also pointing out that wasm is missing some features that make it easier to exploit insecure languages than it is in native code.

Well, easier... except that your hypothetical insecure WASM program has virtually no I/O, so pretty much every exploit is going to need some kind of extra indirection to even get into the WASM program - and once hacked, that WASM program again can barely interact with anything, meaning that again expoitability is going to be pretty situational. I suppose a native program might also have a sandbox that's as restrictive, but that's not exactly common.

Rumsfeld had a good handle on this:


He didn't have it all. The 4th quadrant: unknown knowns

There is a fog to applying stuff we already know but have forgotten and it causes problems.

I've recently started working with rust and wasm - I love the esoteric nature of it - I also hate the surface area that it's creating on the client.

The paper is indeed correct - we did this 20 years ago - same architecture except with JVM instructions.

I'm entirely neutral on the merits of this tech supercycle - there are some great things being built, there are also old potholes getting uncovered that will end with some lessons re-learned.

I was wondering when the last major open computing platform would get locked down with signed binaries.

So with wasm, traditional buffer overflow type stuff becomes xss.

I guess that's a concern, but im not sure its that big of one relative to normal xss.

I think it is an open question whether we truly will be able to safely run untrusted code in a high performance manner on commodity hardware.

It depends on what you mean by "safely". The spectre family of exploits has no general solution and requires specific mitigations. Aside from that, Wasm provides a sandbox that disallows escaping from it. That does leave scribbling on memory inside the sandbox, which is what this paper focuses on.

So for many use cases Wasm does allow what you mention, running unsafe code quickly on normal hardware, and it is being used in production for that purpose.

Note that they didn't break out of the sandbox. So this can't do anything bad to the machine it's running on.

Proof-carrying code? It, too, is old news.

Formal proofs can probably show that spectre and meltdown aren't exploited by enforcing type-safety for all speculative memory accesses, but that requires at least some knowledge of the target processor and may still be slower at processing untrusted input.

There's very little that can be done about rowhammer with formal methods because it breaks the assumptions of any formal model of computation (that values stored to RAM are the same values that will be eventually read from RAM).

WebAssembly: a huge engineering effort to reintroduce memory errors to web applications.

Alternate title: We Learned Nothing About Security From Applets

I don't think that's a fair assessment, and it is also not fair to the designers of WebAssembly. They certainly have spent a lot of thoughts on protecting the host (e.g., browser, underlying OS) from _malicious_ WebAssembly code. This is what we call "host security" in the introduction of the paper. Modulo implementation bugs (which is orthogonal to the design of the language), WebAssembly applications cannot break out of the sandbox more than arbitrary JavaScript already can.

However, what we look at in the paper is "binary security", i.e., whether _vulnerable_ WebAssembly binaries can be exploited by malicious _inputs_ themselves. Our paper says: Yes, and in some cases those write primitives are more easily obtainable and more powerful than in native programs. (Example: stack-based buffer overflows can overwrite into the heap; string literals are not truly constant, but can be overwritten.)

> They certainly have spent a lot of thoughts on protecting the host (e.g., browser, underlying OS) from _malicious_ WebAssembly code.

You say that like the Java Virtual Machine designers didn't do the same thing.

> Modulo implementation bugs (which is orthogonal to the design of the language), WebAssembly applications cannot break out of the sandbox more than arbitrary JavaScript already can.

That has a very familiar sound to it. ;-)

> However, what we look at in the paper is "binary security", i.e., whether _vulnerable_ WebAssembly binaries can be exploited by malicious _inputs_ themselves. Our paper says: Yes, and in some cases those write primitives are more easily obtainable and more powerful than in native programs. (Example: stack-based buffer overflows can overwrite into the heap; string literals are not truly constant, but can be overwritten.)

I think you've highlighted an important subtlety here for sure. Would you say that Java applets were similarly vulnerable?

No, it's a completely different topic. Java applets were "unsafe by design" in that they allowed to escape the sandbox (even as a feature via calling out into native DLLs).

This paper is only about messing up the WASM heap, which might cause the WASM application to crash, but this doesn't cause damage outside the sandbox.

> Java applets were "unsafe by design" in that they allowed to escape the sandbox (even as a feature via calling out into native DLLs).

The design of the Java applet security model did not include being able to escape the sandbox. That was something Microsoft did that deliberately broke the security model. The closest thing Java applets had to "escape the sandbox" was popping up a new window, and even that involved presenting the user with a warning that the window belonged to the applet.

Were applets sandboxed?

I don't think it was a very effective sandbox at the time Java applets were being used, meaning there were bugs and other glaring security issues. Wasm has the same sandboxing as javascript, which is pretty well worn in and not slow for the user (partly because of faster hardware now). It's not simply a repeat of java in the browser, or the RCE exploit that was flash.


Not really, a Java applet could load and call into native DLLs, and once you're in native code, you can do pretty much anything on Windows.

The security model for Java did not include calling native DLLs. That was something that Microsoft added, essentially tossing away the security model in the interest of trying to create a proprietary advantage for Windows in a Java world.


TLDR: Can someone explain if this is because WebAssembly is not doing the same kind of strict validation that NaCL (google native client) was doing ?

nevermind the paper is stupid and not saying there are way of breaking out of the wasm sandbox. It's simply saying if your WASM code was generated from C/C++ code that contain undefined behavior it might still do unexcepted things but those thing does not include breaking out of the sandbox.

This does not make the paper “stupid”.

There needs to be an obligatory "but with better UX" attached to the end of every old is new again statement.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact