This isn't about escaping the vm. It is about changing how the program works inside. Wasm also does not have the concept of read only memory which is another massive security hole.
I was once a huge detractor and naysayer of WASM, but now I'll readily admit that this is the way security "always should have been done".
You can do the same in JavaScript, and it can be very useful. What's your point?
In this case we aren't talking about changing some code in a .js file through a RFI attack. We are talking about changing the behavior of how the node.js interpreter would run the .js file because at the end of the day the interpreter itself is what is getting ran by the os.
If you have specific security concerns, you should be showing actual attacks against wasm runtimes or somehow show that the security model of wasm as a whole will always reduce to an insecure configuration. What you have shown is something that is "exploitable" on pretty much every architecture I know of.
This is another issue:
#include <stdio.h>
#include <stdlib.h>
int main() {
char *s = "world";
s[0] = 'o';
s[1] = 'w';
s[2] = 'n';
s[3] = 'e';
s[4] = 'd';
printf("Hello, %s\n", s);
}How do you propose WASM code is able to change the WASM interpreter behavior?
Could you be misunderstanding WASM's memory model? Are you aware that WASM code can only access explicitly instantiated userspace JS linear memories? Are you aware these memories are just ArrayBuffers in JS userspace?
I'm very far from the only person pointing out a lot of this btw:
https://www.usenix.org/system/files/sec20_slides_lehmann.pdf
https://i.blackhat.com/us-18/Thu-August-9/us-18-Lukasiewicz-...
https://00f.net/2018/11/25/webassembly-doesnt-make-unsafe-la...
You're clearly unable to admit you're wrong. Hard to be charitable about that.