Hacker News Reader

Comment by BubRoss | Hacker News Reader

Can you link to an example of this exploit? Does javascript suffer from the same problem?

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 you just need to have a couple of structs or C string/arrays, living alongside each other and overwrite one of them by writing too much data due to miscalculations of the memory segment holding the data.

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.

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

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.

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.

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

Apparently the force is strong with WebAssembly advocacy.

I meant working examples. Saying "it's insecure!" and then calling your own words evidence doesn't count.

If there are actual exploits or security flaws, then demonstrate them with a working implementation. You seem to be trying to turn a technical discussion into an emotional one.

If you want code examples, just go to the CVE database and compile any memory corruption related to C into a WebAssembly module.

Why should I need to provide new examples when we have plenty to chose from?

internal memory corruption is different from external memory corruption.

It still gets a CVE award in the end.

But they are addressed differently; in particular internal memory corruption is hard to address from a framework perspective, while external memory corruption can be almost entirely eliminated.

Reply on news.ycombinator.com