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

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

hacks.mozilla.org

Post reply on HN
Print view View original

251–260 of 265 posts

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

#251

Post by vanderZwan »

thekingofh wrote: post #236
vanderZwan wrote: post #207

Earlier quoted context omitted.

Does WASM let you run memory as code?

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?

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

#252

Post by thekingofh »

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?

Yes, assuming there's no flaws in the interpreter. But they're all moving full steam ahead in the browsers right now, so imagine it's deemed as safe as javascript. The current push is to divvy up the permissions of certain resources such as sockets and filesystem (browser code don't have filesystem access) and make an API to ensure that modules don't overstep their granted permissions. It'll probably look a lot like node and npm, where you could add a module to your source and know that it can't access things it shouldn't. Pretty exciting stuff. It's a true merger of all languages together under one runtime.

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

#253

Post by thekingofh »

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…

Is there a plan to bring together a bunch of these extensions under one roof with a package/dependency manager similar to cargo or npm, or is it intended to be glued together on the developer side? To me this looks massive, like to be able to pull down modules knowing what permissions they need, and to be able to have some kind of assurances that the code can't misbehave.

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

#254

Post by BubRoss »

pjmlp wrote: post #217
mantap wrote: post #216

Earlier quoted context omitted.

Honestly, given the lack of tooling they have now, it is pretty much perfect from a user's perspective. You are only going to use WASM if you absolutely need the performance. It's just too painful otherwise.

Well, better take care which sites you visit. https://www.infoq.com/news/2019/10/WebAssembly-wasm-maliciou...

Your link basically says that less than 0.01 _percent_ of the top one million websites have webasm cryptocurrency mining. There is no mention of any security flaws. A webasm miner would just eat up a single core while the page is open.

This doesn't seem like much of a red flag to me. If one out of every ten thousand unique sites I visit uses one hypercore while it is opened that isn't going to keep anyone up at night.

On the other hand full video editors, image editors, CAD, 3D content creation programs, silky smooth 3D games, custom video codecs and more have already been made possible due to webasm. Not bad huh?

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

#255

Post by pjmlp »

BubRoss wrote: post #254
pjmlp wrote: post #217

Earlier quoted context omitted.

Well, better take care which sites you visit. https://www.infoq.com/news/2019/10/WebAssembly-wasm-maliciou...

Your link basically says that less than 0.01 _percent_ of the top one million websites have webasm cryptocurrency mining. There is no mention of any security flaws. A webasm miner would just eat up a single core while the page is open. This doesn't seem like much of a red flag to me. If one out of every ten thousand unique sites I visit uses one hypercore while it is opened that isn't going to keep anyone up at night…

Not bad at all, for something that has been possible in Java, Flash, ActiveX, PNaCL before.

Thanks to service workers, the miner won't go away when you close the browser, as by default settings (which normal users don't even know they exist) service workers run on their own processes.

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

#256

Post by pjmlp »

BubRoss wrote: post #233
pjmlp wrote: post #230

Earlier quoted context omitted.

I keep telling the examples, memory corruption, typical C exploits. Apparently the force is strong with WebAssembly advocacy.

I meant working examples. Saying "it's insecure!" and then calling your own words evidence doesn't count. If there are actual exploits or security flaws, then demonstrate them with a working implementation. You seem to be trying to turn a technical discussion into an emotional one.

If you want code examples, just go to the CVE database and compile any memory corruption related to C into a WebAssembly module.

Why should I need to provide new examples when we have plenty to chose from?

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

#257

Post by pjmlp »

afiori wrote: post #250
pjmlp wrote: post #230

Earlier quoted context omitted.

I keep telling the examples, memory corruption, typical C exploits. Apparently the force is strong with WebAssembly advocacy.

internal memory corruption is different from external memory corruption.

It still gets a CVE award in the end.

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

#258

Post by callahad »

pjmlp wrote: post #202
jdance wrote: post #92

Earlier quoted context omitted.

I like the JVM and have done lots of code for it, but the java download&install / setting up PATH / non native gui-look / no exe-files / should i get se/ee/jre/sdk etc etc must be a big contributing factor to its lack of being more popular (client side). A lot of the experience has been clumsy, ugly and unintuitive from the start

WebAssembly developer experience is also not the most friendly one, with its mix of toolchains, specially if one is on Windows. Oh, and debugging is still at printf level style and reading raw bytecodes.

> debugging is still at printf level style and reading raw bytecodes

Wasmtime has had support for source-level debugging via lldb or gdb for a few months https://hacks.mozilla.org/2019/09/debugging-webassembly-outs...

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

#259

Post by lambda »

afiori wrote: post #245
lambda wrote: post #154

Earlier quoted context omitted.

What would allow other languages to represent unforgeable pointers as a first class concept and not C/C++/Rust? Forging a pointer is UB in all of these languages as far as I know. It seems like you should be able to have opaque types that represent these unforgeable pointers which you can't do arithmetic on or cast to raw pointers, but can access values in type safe ways, or provide a view to a byte slice which does…

In unsafe rust you can arbitrarily increase the length of a vector/string by modifying the stored length. You do not need to forge the pointer itself to break the pointer's invariant.

You would need to do either static or dynamic bounds checking when accessing memory via these capabilities. You obviously can't just give arbitrary code a pointer and let it read however far it wants past the end of it.

Given that most code in Rust is safe code and includes bounds checks before access, you should be able to have the verifier rely on those when they exist, and add in bounds checks in cases in which the access is not protected by a bounds check.

Maybe that would be intractable, or to inefficient to be worth it with all of the extra bounds checks. I'm not sure. I'm asking because it's something that I feel should be possible, but I haven't been involved in the research or development, so I'm wondering if those who have been more involved have references to discussion about the topic.

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

#260

Post by pjmlp »

callahad wrote: post #258
pjmlp wrote: post #202

Earlier quoted context omitted.

WebAssembly developer experience is also not the most friendly one, with its mix of toolchains, specially if one is on Windows. Oh, and debugging is still at printf level style and reading raw bytecodes.

> debugging is still at printf level style and reading raw bytecodes Wasmtime has had support for source-level debugging via lldb or gdb for a few months https://hacks.mozilla.org/2019/09/debugging-webassembly-outs...

That doesn't look like production ready, nor integrated into browser developer tools.
Post reply on HN