Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WASM Is the New CGI

roborooter.com

Post reply on HN
Print view View original

161–170 of 311 posts

Re: WASM Is the New CGI

#161

Post by jauntywundrkind »

VyseofArcadia wrote: post #146
jauntywundrkind wrote: post #120

Earlier quoted context omitted.

Every native app has to be run in a gigantic special OS when it could be a small webapps running in a medium sized browser. Many many ChromeOS (web based consumer OS) laptops are 4GB of ram. You do not want to try that with any normal OSes.

But the browser is running in that gigantic special OS. It's not like the OS magically disappears.

I've already mentioned ChromeOS as one counter-example.

SerenityOS and Ladybird browser forked but until recently had a lot of overlap.

LG's WebOS is used on a range of devices, derived from the Palm Pre WebOS released in 2009.

The gigantic special OS is baggage which already has been cut loose numberous times. Yes you can run some fine light Linux OS'es in 4GB but man, having done the desktop install for gnome or kde, they are not small at all, even if their runtime is ok. And most users will then go open a web browser anyways. It's unclear to me why people clutch to the legacy native app world, why this other not-connected mode of computing has such persistent adherency to it. The web ran a fine mobile OS in 2009; Palm Pre rocked. It could today.

Re: WASM Is the New CGI

#162

Post by mdhb »

perching_aix wrote: post #160
vbezhenar wrote: post #59

Earlier quoted context omitted.

Java and Flash failed to deliver its promise of unbreakable sandbox where one could run anything without risking compromising host. They tried, but their implementations were ridden with vulnerabilities and eventually browsers made them unusable. Other mentioned technologies didn't even promise that, I think. JavaScript did deliver its promise of unbreakable sandbox and nowadays browser runs JavaScript, downloaded fr…

> JavaScript did deliver its promise of unbreakable sandbox Aren't its VM implementations routinely exploited? Ranging from "mere" security feature exploits, such as popunders, all the way to full on proper VM escapes? Like even in current day, JS is ran interpreted on a number of platforms, because JIT compiling is not trustworthy enough. And I'm pretty sure the interpreters are no immune either.

There were a bunch of things missing from OPs description around the security considerations of Wasm but it has a lot of other stuff on top of what the browser provides when it’s executing JavaScript.

The primary one is its idea of a “capability model” where it basically can’t do any kinds of risky actions (I.e touch the outside world via the network or the file system for example) unless you give it explicit permissions to do so.

Beyond that it has things like memory isolation etc so even an exploit in one module can’t impact another and each module has its own operating environment and permission scope associated with it.

Re: WASM Is the New CGI

#163

Post by mike_hearn »

junto wrote: post #8

Can someone explain to me what the difference really is between WASM and older tech like Java Applets, ActiveX, Silverlight and Macromedia Flash, because they don’t really sound much different to me. Maybe I’m just old, but I thought we’d learnt our lesson on running untrusted third party compiled code in a web browser. In all of these cases it’s pitched as improving the customer experience but also conveniently push…

Conceptually, they aren't that different. The details do matter though.

WASM on its own isn't anything special security-wise. You could modify Java to be as secure or actually more secure just by stripping out features, as the JVM is blocking some kinds of 'internal' security attacks that WASM only has mitigations for. There have been many sandbox escapes for WASM and will be more, for example this very trivial sandbox escape in Chrome:

https://microsoftedge.github.io/edgevr/posts/Escaping-the-sa...

... is somewhat reminiscent of sandbox escapes that were seen in Java and Flash.

But! There are some differences:

1. WASM / JS are minimalist and features get added slowly, only after the browser makers have done a lot of effort on sandboxing. The old assumption that operating system code was secure is mostly no longer held whereas in the Flash/applets/pre-Chrome era, it was. Stuff like the Speech XML exploit is fairly rare, whereas for other attempts they added a lot of features very fast and so there was more surface area for attacks.

2. There is the outer kernel sandbox if the inner sandbox fails. Java/Flash didn't have this option because Windows 9x didn't support kernel sandboxing, even Win2K/XP barely supported it.

3. WASM / JS doesn't assume any kind of code signing, it's pure sandbox all the way.

Re: WASM Is the New CGI

#164

Post by torginus »

flohofwoe wrote: post #105
torginus wrote: post #87

Earlier quoted context omitted.

>Browsers definitely use a form of JIT-ing for WASM I (and the article) wasn't referring to this kind of JIT. I was referring to the ability to dynamically create or modify methods or load libraries while the app is running (like `DynamicMethod` in .NET). Afaik WASM even in the browser does not allow modifying the blob after instantiation. The thing you are referring to puzzles me as well. I initially thought that WA…

> Afaik WASM even in the browser does not allow modifying the blob after instantiation. ...not your own WASM blob, but you can build a new WASM blob and run that. > The thing you are referring to puzzles me as well... Yes, compilers emit WASM, but that WASM is just a bytecode (similar to JVM or .NET bytecode but even higher level because WASM enforces 'structured control flow') and needs to be compiled to actual mach…

I feel like I need to be a bit more frank

> WASM is just a bytecode (similar to JVM or .NET bytecode but even higher level ...

Yes, and I think this was a poor engineering choice on behalf of WASM engineering team, instead of using something much closer to actual assembly. And we are grappling with long startup times and lots of compiler infra pushed into the client because of that.

> ...not your own WASM blob, but you can build a new WASM blob and run that.

another baffling limitation, considering you can modify your C#, Java or even native code at runtime.

Unless they are working around some constraint unknown to me, in which case I'd love to know about what it is, they made bad technical decisions in the design.

Re: WASM Is the New CGI

#165

Post by esrauch »

perching_aix wrote: post #160
vbezhenar wrote: post #59

Earlier quoted context omitted.

Java and Flash failed to deliver its promise of unbreakable sandbox where one could run anything without risking compromising host. They tried, but their implementations were ridden with vulnerabilities and eventually browsers made them unusable. Other mentioned technologies didn't even promise that, I think. JavaScript did deliver its promise of unbreakable sandbox and nowadays browser runs JavaScript, downloaded fr…

> JavaScript did deliver its promise of unbreakable sandbox Aren't its VM implementations routinely exploited? Ranging from "mere" security feature exploits, such as popunders, all the way to full on proper VM escapes? Like even in current day, JS is ran interpreted on a number of platforms, because JIT compiling is not trustworthy enough. And I'm pretty sure the interpreters are no immune either.

I think "routinely" is overstating it, billions people are running arbitrary JS on a daily basis and no meaningful number of them are being infected by malware.

Browser surface attracts the most intense security researcher scrutiny so they do find really wild chains of like 5 exploits that could possibly zero day, but it more reflects just how much scrutiny it has for hardening, realistically anything else will be more exploitable than that, eg your Chromecast playing arbitrarily video streams must he more exploitable than JS on a fully patched Chrome.

Re: WASM Is the New CGI

#167

Post by Tepix »

I disagree. In particular for me the allure for CGI was its simplicity. Have you played around with WASM in the browser? It involves way too many steps to get it integrated into the web page and to interact with it.

I let chatgpt do the tedious work, have a look at a minimal example:

https://chatgpt.com/share/6707c2f3-5840-8008-96eb-e5002e2241...

Re: WASM Is the New CGI

#168

Post by flohofwoe »

torginus wrote: post #164
flohofwoe wrote: post #105

Earlier quoted context omitted.

> Afaik WASM even in the browser does not allow modifying the blob after instantiation. ...not your own WASM blob, but you can build a new WASM blob and run that. > The thing you are referring to puzzles me as well... Yes, compilers emit WASM, but that WASM is just a bytecode (similar to JVM or .NET bytecode but even higher level because WASM enforces 'structured control flow') and needs to be compiled to actual mach…

I feel like I need to be a bit more frank > WASM is just a bytecode (similar to JVM or .NET bytecode but even higher level ... Yes, and I think this was a poor engineering choice on behalf of WASM engineering team, instead of using something much closer to actual assembly. And we are grappling with long startup times and lots of compiler infra pushed into the client because of that. > ...not your own WASM blob, but y…

> they made bad technical decisions in the design

Considering that the most important design requirement was to have a security model that's good enough for running untrusted code in web browsers at near native performance, I think the WASM peeps did a pretty good job.

Your requirements may be different, but then maybe WASM simply isn't the right solution for you (there are plenty of alternatives outside web browsers after all).

Re: WASM Is the New CGI

#169

Post by adrian17 »

kgeist wrote: post #103
Laremere wrote: post #49

Earlier quoted context omitted.

Wasm has a great benefits over those technologies: - Wasm has verification specification that wasm bytecode must comply to. This verified subset makes security exploits seen in those older technologies outright impossible. Attacks based around misbehaving hardware like heartbleed or rowhammer might still be possible, but you, eg, can't reference memory outside of your wasm's memory by tricking the VM to interpret a n…

Btw, is WASM really more secure? JVM and .NET basically have capability-based security thanks to their OOP design together with bytecode verification: if you can't take a reference to an object (say, there's a factory method with a check), you can't access that object in any way (a reference is like an access token). As far as I understand, in WASM memory is a linear blob, so if I compile C++ to WASM, isn't it possib…

AFAIK you’re correct.

Also see: https://www.usenix.org/conference/usenixsecurity20/presentat...

„We find that many classic vulnerabilities which, due to common mitigations, are no longer exploitable in native binaries, are completely exposed in WebAssembly. Moreover, WebAssembly enables unique attacks, such as overwriting supposedly constant data or manipulating the heap using a stack overflow.”

My understanding is that people talking about wasm being more secure mostly talk about the ability to escape the sandbox or access unintended APIs, not integrity of the app itself.

Re: WASM Is the New CGI

#170

Post by pjmlp »

kaba0 wrote: post #157
iforgotpassword wrote: post #41

Earlier quoted context omitted.

That's a bit oversimplified. I had this thought too and tried to figure out why this is different, and I think there are some major points. The biggest one is in which order they were built and designed. If we take Java and ask why applets didn't take off since they could do everything WASM offers and more, two things come to mind: it was fucking slow on contemporary machines, and the gui framework sucked. WASM is th…

Wasm is more open, because we effectively have 1.5 browsers left, and whatever google decides will be the de facto “web standard” everyone should follow. If google were pushing for a slightly revamped jvm/applet model, that would be the standard (as the JVM is as open/standardized as it gets)

Ironically if it was today instead of 2010, Mozilla refusing to adopt PNaCL would hardly matter.
Post reply on HN