Live data from Hacker News

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

hacks.mozilla.org

221–230 of 265 posts

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

#221
One pretty annoying thing with WASM is that it is pretty hard to generate due to requiring a structured control flow so anyone generating it must implement relooper och stackifier. Is there any work on solving this issue?

http://troubles.md/posts/why-do-we-need-the-relooper-algorit...

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

#222
post #190

Earlier quoted context omitted.

Then get to use Visual C++, which does bounds checking on collection types (array, string, vector,...), memory dumps leaks at exit. Or Solaris SPARC and iOS compilers that make use of hardware memory tagging. Clang and GCC do need extra flags to enable FORTIFY mode though. However on Android FORTIFY is now a requirement and future versions will make use of memory tagging on ARM hardware. So ironically something like…

> iOS compilers that make use of hardware memory tagging No iOS devices ship with ARMv8.5, so while I think compilers are implementing this today I am not sure if Xcode ships with this or if it's functional. > So ironically something like Android does have a better sandboxing model as WebAssembly. …you're not understanding what sandboxing means.

Apple has their own CPUs,

https://developer.apple.com/documentation/security/preparing...

I do understand what sandboxing means, and how WebAssembly advocates keep overselling its security capabilities, by ignoring issues that other bytecode formats have taken a more serious approach, already in the mid-60's.

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

#223
post #192

Earlier quoted context omitted.

Except that you load code from multiple sources and one could eventually have a piece of JavaScript code that makes use of such behaviour to have access to some feature that by default is not accessible. I rather let WebAssembly turn out to be the next Flash, when black hats start looking at it with the same care they had before, no need to waste cycles myself, as it is a lost battle against WebAssembly advocacy.

I don't understand what you mean by "a piece of JavaScript code that makes use of such behaviour". Webasm is accessed by javascript, not the other way around. This really sounds like you have an axe to grind with webasm for some reason, the things you saying seems like grasping at straws. It already works in browsers, so if there is something to exploit you could demonstrate it with a few files on github.

Yep, overselling security.

I guess everyone knows how to corrupt memory with C code, no need for github files.

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

#224
post #193

Earlier quoted context omitted.

Yeah, but then one should acknowledge those issues, and not advocate WebAssembly as if there weren't hundreds of other attempts since the late 50's.

They don't mention them because their focus is on other aspects of safety.

Either one is actually serious about security across the whole stack, or not.

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

#225
post #223

Earlier quoted context omitted.

I don't understand what you mean by "a piece of JavaScript code that makes use of such behaviour". Webasm is accessed by javascript, not the other way around. This really sounds like you have an axe to grind with webasm for some reason, the things you saying seems like grasping at straws. It already works in browsers, so if there is something to exploit you could demonstrate it with a few files on github.

Yep, overselling security. I guess everyone knows how to corrupt memory with C code, no need for github files.

Are you saying webasm will crash or that it is insecure? These are two different things and you seem to be conflating them. In your posts you have said that it is insecure but when you talk about specifics it just seems to be about crashing. Then when pressed you avoid any examples.

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

#226
post #222

Earlier quoted context omitted.

> iOS compilers that make use of hardware memory tagging No iOS devices ship with ARMv8.5, so while I think compilers are implementing this today I am not sure if Xcode ships with this or if it's functional. > So ironically something like Android does have a better sandboxing model as WebAssembly. …you're not understanding what sandboxing means.

Apple has their own CPUs, https://developer.apple.com/documentation/security/preparing... I do understand what sandboxing means, and how WebAssembly advocates keep overselling its security capabilities, by ignoring issues that other bytecode formats have taken a more serious approach, already in the mid-60's.

Pointer authentication≠memory tagging. The former requires ARMv8.3 and is in the A12 processor, and the latter is not in any hardware that Apple is currently shipping.

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

#227

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.

Technically I agree, but nowadays with 5G+Edge computing, where low latency application requirements are essential, there will be other performance constraints not tackled by Java that needs new solutions. Previous JVM attempts mostly focused on "write once, run anywhere". But now, "anywhere" means "anywhere and quickly" :)

With proper implementation JVM could be kept running and loading applet would be extremely fast.

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

#228

Earlier quoted context omitted.

Web developers don't seem to have any concern about using gigantic quantities of memory. Don't hire a web developer to develop for games. :)

It's almost as if spending time optimizing memory usage isn't worth it because server RAM is cheap!

What does server RAM have to do with modern web development, where the vast majority of the work is done on the frontend?

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

#229
post #170
post #86

Earlier quoted context omitted.

> 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).

Just to help others searching for "confused lieutenant," I believe it's usually known as the "confused deputy problem," perhaps as a reference to Barney Fife. I do like the image of a confused lieutenant though.

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

#230
post #223

Earlier quoted context omitted.

Yep, overselling security. I guess everyone knows how to corrupt memory with C code, no need for github files.

Are you saying webasm will crash or that it is insecure? These are two different things and you seem to be conflating them. In your posts you have said that it is insecure but when you talk about specifics it just seems to be about crashing. Then when pressed you avoid any examples.

I keep telling the examples, memory corruption, typical C exploits.

Apparently the force is strong with WebAssembly advocacy.

Post reply on HN