The Bytecode Alliance: Building a secure, composable future for WebAssembly • Hacker News Board

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#261

Post by pjmlp » Fri, Nov 15, 2019, 6:47 AM UTC

afiori wrote: post #246

tasogare wrote: post #242

Earlier quoted context omitted.

Yes the concept, as well as implementations, existed for decades. I think WASM is hype because it comes from the Web/JS community and they have good communication, but technically there is nothing new under the sun.

I would say that being a success instead of a failure is something new. The JVM was successful but not for plugins, nor for embedded safety. Also the fact that many vendors have reached a consensus on both a MVP and an update process to future features looks like a win. If Sun, Microsoft, Apple, and Google had all been on board with the (supposedly free software) JVM the story would have been very different.

Ironically WebAssembly advocacy keeps being defensive against JVM, while cleverly forgetting the dozens of other formats that also offered similar capabilities, including executing C derived languages.

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#262

Post by hz10 » Fri, Nov 15, 2019, 2:53 PM UTC

JoshTriplett wrote: post #2

I'm one of the folks working with the Alliance, and I'm incredibly excited about WebAssembly outside the browser. Happy to answer questions. Imagine extensions for applications or databases, written in any language you want, with no ability to exfiltrate data. Imagine supporting a safe plugin API that isn't just for C and languages that FFI to C, but works natively with safe datatypes. Today, if you want to be extens…

Fantastic! Since I made quite a few Silverlight RIAs, WASM is like Silverlgitht on steroids. I am surprised that Uno Platform is not a founding member of the Alliance. AFAIK, they are the most devoted group for WASM (hope not offending you). I use Uno Platform to make WASM apps with ease and pleasure. The current major issue is the long startup time. Hope there will be a significant improvement in this area soon.

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#263

Post by rkangel » Fri, Nov 15, 2019, 4:20 PM UTC

vanderZwan wrote: post #251

thekingofh wrote: post #236

Earlier quoted context omitted.

No. Marking memory as executable is a native machine level capability (as in x86_64 assembly machine instructions). Wasm is a stack machine interpreter that can read only Wasm binaries. The binary format is essentially just a compressed/minimized form of the bytecode format, which used to essentially be an AST of the original source code, but now I believe they modified it a bit to be more analogous to hypothetical m…

That's what I thought. Then that's one whole category of exploits that no longer applies, no?

That's true, but that's a class of exploits that is mostly impossible anyway (except in an embedded environment). Most systems that have an MMU ensure that no page is both writeable and executable, meaning you can't inject code. This forces attackers to use ROP.

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#264

Post by afiori » Sun, Nov 17, 2019, 8:27 PM UTC

pjmlp wrote: post #257

afiori wrote: post #250

Earlier quoted context omitted.

internal memory corruption is different from external memory corruption.

It still gets a CVE award in the end.

But they are addressed differently; in particular internal memory corruption is hard to address from a framework perspective, while external memory corruption can be almost entirely eliminated.

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#265

Post by danudey » Wed, Nov 27, 2019, 1:35 AM UTC

afiori wrote: post #244

devwastaken wrote: post #198

Earlier quoted context omitted.

This isn't entirely accurate. Exploitations in whatever code is converted to wasm instructions still work inside the wasm memory space. As in, if you write your program in c, python, whatever, and put it in wasm, then have a wasm extension system of some sort - if that c or python is exploitable, then whatever external access that wasm instance has is now useable. And whatever memory is in the memory space can be mod…

The point is that you can more easily and clearly sandbox the wasm plugin. If the python implementation tries to send http requests but the wasm sandbox has no network access you are safer in wasm than in python.

Unless you choose to sandbox your python. Obviously the language itself doesn't support this, but most OSes have functionality for this that can be applied to any application or code, not just wasm.