http://troubles.md/posts/why-do-we-need-the-relooper-algorit...
The Bytecode Alliance: Building a secure, composable future for WebAssembly
221–230 of 265 posts
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#222Earlier 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.
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
#223Earlier 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.
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
#224Earlier 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.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#225Earlier 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.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#226Earlier 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.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#227Earlier 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" :)
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#228Earlier 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!
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#229Earlier 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).
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#230Earlier 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.
Apparently the force is strong with WebAssembly advocacy.