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

111–120 of 265 posts

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

#111

Post by pjmlp »

gridlockd wrote: post #98
pjmlp wrote: post #53

Earlier quoted context omitted.

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

How would you enforce bounds checking while supporting unsafe languages?

That is exactly the point, don't advertise WebAssembly as safe bytecode, if unsafe languages are part of the picture without any kind of control.

Secondly, nor ISO C or ISO C++ forbid implementations that do bounds checking by default. In fact that is what most modern compilers do by default in debug mode.

Finally look at memory tagging in Solaris SPARC ADI, Apple iOS or the upcoming ARM extensions support on Android for how bounds checking is enforced at hardware level while supporting unsafe languages.

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

#112

Post by AgentME »

greatgib wrote: post #22

So much bullshit, in the end just to strip a little bit more the user and the developer of any liberty. The dream of us corp controlled appstore for pc desktops. Who will control what you can do through the sandbox? Intel, Mozilla, Google... So one day your soft will have to be signed by them and will refuse to let you adblock ... For your own safety...

When you use WebAssembly, you're in control of the sandbox. You can pass things into the sandbox and let the module use it. There's no signing/certificate/appstore system tied to WebAssembly.

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

#113

Post by weberc2 »

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…

I'm particularly interested in a world where wasm binaries replace (or supplement) containers (or even VMs?). I'm specifically imagining Kubernetes or AWS Lambda but with direct wasm execution (instead of wasm-in-container or wasm-in-VM). I'd be curious if anyone has put more thought into this and what possibilities they envision.

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

#114

Post by kllrnohj »

pcwalton wrote: post #96
armitron wrote: post #87

Earlier quoted context omitted.

It's not like what you propose hasn't been tried before. The main practical issue that I don't see this post address, is the combinatorial explosion that stems from fine-grained sandboxing of any complex application. There are bound to be executable paths through the state space that both pass initial muster and can be used by an attacker to craft a sandbox bypass. In other words, finegrained sandboxing does not solv…

You seem to be arguing that sandboxing is not a security benefit. On the contrary, sandboxing is maybe the security success story of the past decade.

System sandboxing (virtualization) yes. "OS" sandboxing (containers) yes. Process sandboxing yes. None of those need or benefit from webasm.

In-process sandboxing, where wasm competes, is, if anything, the security failure of the past decade. JS in browsers has been a constant, never ending battle. And it just hard-failed thanks to spectre.

The idea of everyone rolling their own, hardened syscall interfaces is a straight up terrible idea if security is your goal.

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

#115

Post by Hitton »

>So how can you protect your users against these threats in today’s software ecosystem?

>You could subscribe to a monitoring service that alerts you when a vulnerability is found one of your dependencies. But this only works for those that have been found. And even once a vulnerability has been found, there’s a good chance the maintainer won’t be able to fix it quickly. For example, Snyk found in the npm ecosystem that for the top 6 packages, the median time-to-fix (measured starting at the vulnerability’s inclusion) was 2.5 years.

Sometimes it looks like writers think that the average reader is complete idiot. How is that supposed to be example? First they say that it takes long time fix once the bug is found and as illustration they give period starting with introduction of vulnerability?

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

#117

Post by hinkley »

Hitton wrote: post #115

>So how can you protect your users against these threats in today’s software ecosystem? >You could subscribe to a monitoring service that alerts you when a vulnerability is found one of your dependencies. But this only works for those that have been found. And even once a vulnerability has been found, there’s a good chance the maintainer won’t be able to fix it quickly. For example, Snyk found in the npm ecosystem th…

We can't even get software developers to use sane metrics. Good luck getting Masters of Fine Arts people to use them property to describe software. Especially when we've provided such a stellar example.

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

#118

Post by muricula »

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 the time in javascript JITs), there's nothing to stop you from ropping to gadgets to open your own sockets without going through any in-process checks.

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

#119

Post by Narishma »

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…

> Imagine embedding a WebAssembly runtime like wasmtime, and telling people they can write their extensions in any language they want.

Is that desirable? Won't it lead to a bloated mess with every extension dragging in a different language runtime with it?

Post reply on HN