191–200 of 265 posts
Earlier quoted context omitted.
> In fact that is what most modern compilers do by default in debug mode. Assuming that “debug mode” is -g or equivalent, then I have not seen a modern compiler that does this.
He’s probably talking about instrumentation (valgrind, ASAN etc.) That’s part of why running instrumented code feels like running python.
Earlier quoted context omitted.
Any kind of typical C memory corruption that you can think of that fails to validate the buffer sizes that you give as parameters. WebAssembly memory access bytecodes only do bounds checking of the linear memory block that gets allocated to the module. You then do your own memory management taking subsets from that memory block and assigning it to the respective internal heap allocations or global memory blocks. So y…
Wouldn't that just corrupt your own program? If there is a security flaw you could demonstrate it.
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.
Earlier quoted context omitted.
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.
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?
Earlier quoted context omitted.
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.
WebAssembly strongly sandboxes the module from affecting the world outside of it, not from affecting itself. Isn't that the usual use of the word sandbox? The sandbox imposes a boundary between the inside and outside, but it doesn't directly change how things work on the inside. It might be nice to have features for enforcing memory bounds within a module, but I wouldn't call those sandboxing, or call the lack of tho…
Some other bytecodes like Unisys ClearPath mainframes follow the same approach when using unchecked bounds access.
WebAssembly folks just hand wave it as not an issue.
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…
As in, if you write your program in c, python, whatever, and put it in wasm, then have a wasm extension system of some sort - if that c or python is exploitable, then whatever external access that wasm instance has is now useable. And whatever memory is in the memory space can be modified.
This is an important distinction. Wasm should be thought of as a tool to containerise execution and memory if the implimentation is proven to do so.
Earlier quoted context omitted.
Wouldn't that just corrupt your own program? If there is a security flaw you could demonstrate it.
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.
With all due respect, that doesn't make WebAssembly unsafe in any way.
By the same logic, any program that takes any kind of user input is unsafe because the program could trust data it should not trust and then execute incorrectly.
If a program does not validate (untrusted) input then it is the program's fault. Not the input's fault or the input-producing-method's fault.
I agree with where you're coming from though. People are going to make mistakes and if the average developer has to interpret blobs of bits as meaningful data structures just to get things done, then we are going to see a lot of these types of problems. However, there are already projects in the works that are automating the $LANGUAGE to Wasm glue code which should completely mitigate this issue.
The wasm committee made many mistakes by treating it as an idea on paper, and not writing the actual implimenting software.
This has resulted in significant fragmenting of implimentation, each less trustworthy than the last.
If any software is going to advertise safety, it must prove it. That's done through the feedback cycle and careful development. The only ones that have this are in browsers.
Yet browsers have their own dubious implimentation, integrated with their JavaScript environment.
Unless wasm decides on a set of standard runtimes that become trustworthy there will not be a wasm outside the browser.
For example, when I search for python, I get python. There's still other pythons, but there's the python. This is true of all other software used. Wasm is failing to do that.