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

161–170 of 265 posts

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

#161

Post by saagarjha »

pjmlp wrote: post #53
vbezhenar wrote: post #37

Earlier quoted context omitted.

Java failed to deliver safe sandbox. Browsers finally booted it because of numerous vulnerabilities. For me wasm looks exactly like another JVM attempt, but it's a good thing, because the idea is good, we just need better implementation. Now if I don't need sandbox, it's going to be a tougher sell. But who knows, may be it'll outperform JVM on bare metal some day.

WebAssembly also has its security issues. Lack of bounds checking for multiple data accesses mapped to the same linear memory block.

Right, but this isn’t a sandboxing issue.

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

#162

Post by saagarjha »

pjmlp wrote: post #47
JoshTriplett wrote: post #39

Earlier quoted context omitted.

The security here is based on sandboxing code and providing limited capabilities. If you're embedding wasm, you choose what capabilities to give the sandbox. For instance, if a game wants to support mods via wasm, it could give the mods APIs to the game world but not to the network or filesystem. A database plugin might have access to interpret a database object handed to it but not exfiltrate data over the network.…

What about fixing the lack of bounds checking when multiple data elements are mapped into the same linear memory block? This leaves the door open for trying to influence behaviour of C and C++ generated WebAssembly modules, by corrupting their internal state via invalid data.

If you give a sandbox a capability and then there’s a bug in it, there’s always a chance that it will maliciously access those privileged resources. The only way I can see of protecting against logic bugs like these is better tooling.

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

#163

Post by saagarjha »

pjmlp wrote: post #130
AgentME wrote: post #108

Earlier quoted context omitted.

The cross-language interoperability of WebAssembly seems practically like a happy side-effect of its design; I don't think it would look much differently at present if it had originally been built to target only C (in a sandboxable way). Most of the article still applies even if you ignore other language support. The first priority for WebAssembly seems to be making things strongly sandboxed.

Actually it fails to properly sandbox C derived languages versus what hardware memory tagging like SPARC ADI and ARM are capable of, because it doesn't do bounds checks inside linear memory blocks.

Hardware memory tagging is not a requirement for sandboxing. Actually, hardware memory tagging doesn’t even fully restrict out-of-bounds accesses because it’s granularity is usually larger than a byte.

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

#164

Post by saagarjha »

kllrnohj wrote: post #79
thrax wrote: post #36

Earlier quoted context omitted.

You give it a heap. It doesn't allocate memory. It may allocate within its own heap, using whatever allocator/gc strategy it inherits from it's host language.

Which means it can't free. But that's also not accurate, anyway, there's a brk() method to grow the heap. Which is such a bad starting point for a new runtime.

Would it be impossible to implement mmap and sbrk in the runtime?

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

#165

Post by saagarjha »

muricula wrote: post #118

How can I learn more about how nanoprocesses and the wasmtime sandbox work under the hood? Searching the repo on github for common keywords doesn't turn up much. Are nanoprocesses like Windows picoprocesses somehow, or are multiple "processes" running in the same address space? If so, you can probably exfiltrate data between nanoprocesses with spectre. Additionally, if you get RCE in the wasm JIT (this happens all th…

> or are multiple "processes" running in the same address space

Yes.

> If so, you can probably exfiltrate data between nanoprocesses with spectre.

Right, this is mentioned in the article. (TL;DR if this is a concern for you don’t use the sandbox, at least not until someone’s figured out how to implement timing protection.

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

#166

Post by mantap »

shmolyneaux wrote: post #74
Animats wrote: post #58

The primary use case for WebAssembly is malware.[1] We're probably going to regret letting WebAssembly into the browser. Because vendors won't let it be locked down so much that it can't be used for ads and tracking. Which means it has to allow malware. [1] https://www.tu-braunschweig.de/Medien-DB/ias/pubs/2019-dimva...

Thanks for the reference. Just so it's clear, the definition of "malware" used here is in-browser crypto mining and obfuscation. Only 1 in 600 of the top 1 million sites use WebAssembly. WebAssembly doesn't actually provide a new vector for malware.

WebAssembly is still very immature. It unsurprising that it has such a low adoption right now.

I think the real problem with webassembly would be if it becomes too popular and starts to become a JS competitor rather than a complement to JS.

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

#167

Post by hinkley »

nabla9 wrote: post #71

JVM was supposed to be this. Gosling said publicly that JVM is more important than Java. . Many things went wrong. Microsoft was actively sabotaging JVM. They implemented very fast JVM for Explorer and their operating system that intentionally broke the JVM 1.1 standard. See Sun vs Microsoft 1997. Microsoft lost and paid damages. .NET was created to do more damage.

You can blaze a trail that others literally follow, or you can blaze a trail that others figuratively follow.

The JVM is definitely more important than Java. But it might not be the most important VM, let alone the most important thing in software.

And other languages/platforms emulating that plan doesn't diminish the JVM, except numerically.

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

#168

Post by kllrnohj »

saagarjha wrote: post #164
kllrnohj wrote: post #79

Earlier quoted context omitted.

Which means it can't free. But that's also not accurate, anyway, there's a brk() method to grow the heap. Which is such a bad starting point for a new runtime.

Would it be impossible to implement mmap and sbrk in the runtime?

mmap is arguably the only thing it should have had in the first place. brk/sbrk is fairly dead.

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

#169

Post by chii »

syrusakbary wrote: post #33
giancarlostoro wrote: post #6

I saw a comment about this on HN before, forgot who it was by. But it was interesting, someone mentioned the spec for WebAssembly is generic enough to apply outside of the web. I'm suspecting we'll see languages converting on node.js a la web assembly for back-end logic in your preferred language, but in any runtime this includes NodeJS but also excludes it as we see future runtimes. What's your view on this? Also, A…

> It would also be interesting to have an embedded WebAssembly plugin runtime, much like Lua is used all over now that you mention all those examples. Completely! Here are some examples on how to embed Wasm in different languages: * Python - https://github.com/wasmerio/python-ext-wasm * PHP - https://github.com/wasmerio/php-ext-wasm * Go - https://github.com/wasmerio/go-ext-wasm * .Net - https://github.com/migueldeic…

Darn, they are missing java :(

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

#170

Post by chii »

weberc2 wrote: post #86
jkoberg wrote: post #82

Earlier quoted context omitted.

So, like, Java?

> Imagine extensions for applications or databases, written in any language you want, with no ability to exfiltrate data How does Java preclude plugins exfiltrating data? Downvoters: I’m not trying to be sacrilegious; I genuinely don’t know the answer.

You can use a security manager and define permission on what the loaded java code can do.

Unfortunately, it's fraught with danger because of the confused lieutenant issue ( you'd need to give parts of the app permission but not others - doing so isn't trivial).

Post reply on HN