31–40 of 111 posts
I am wondering if this technique could be hybridized with abstract interpretation or partial evaluation, which are known techniques in compilers. In essence, this would become a type of concolic execution.
This company has an x86-to-WASM compiler that lets you execute arbitrary binaries in the browser. Also a JVM to WASM transpiler. There's a fantastic Meetup presentation given by one of them where they show running a C++ multiplayer game with both client AND server running in a browser, using WebRTC as a networking polyfill. Really mindblowing: https://youtu.be/7JUs4c99-mo?t=167
It gives a new meaning to the slogan "write once, run everywhere".
Earlier quoted context omitted.
There is a very big difference: ActiveX was native code that was literally running on your system with full access to system calls. CheerpX is a Virtual Machine environment, it JIT compiles Wasm code from x86 binaries and it is fully sandboxed by the browser. It _cannot_ access your system even if it tried.
It can still be exploited the Applets/Flash way, by forcing the internal memory to become corrupted and with it change its behaviour.
This company has an x86-to-WASM compiler that lets you execute arbitrary binaries in the browser. Also a JVM to WASM transpiler. There's a fantastic Meetup presentation given by one of them where they show running a C++ multiplayer game with both client AND server running in a browser, using WebRTC as a networking polyfill. Really mindblowing: https://youtu.be/7JUs4c99-mo?t=167
At what point does the browser become an "os", what's next? Chrome hypervisor?
Earlier quoted context omitted.
There is a very big difference: ActiveX was native code that was literally running on your system with full access to system calls. CheerpX is a Virtual Machine environment, it JIT compiles Wasm code from x86 binaries and it is fully sandboxed by the browser. It _cannot_ access your system even if it tried.
It can still be exploited the Applets/Flash way, by forcing the internal memory to become corrupted and with it change its behaviour.
Likening it to Java applets or Flash is deceptive -- yes, you can still hack them and exploit vulnerabilities. But the scope of what you can do with such vulnerabilities is wildly, dramatically different. Even when sandboxed, Flash has an enormously wider attack surface to play with. WebAssembly has barely anything.
It's like the difference between patching a leak in your roof with a sponge vs tar paper. In theory, water could find a path through the tar paper.
This company has an x86-to-WASM compiler that lets you execute arbitrary binaries in the browser. Also a JVM to WASM transpiler. There's a fantastic Meetup presentation given by one of them where they show running a C++ multiplayer game with both client AND server running in a browser, using WebRTC as a networking polyfill. Really mindblowing: https://youtu.be/7JUs4c99-mo?t=167
At what point does the browser become an "os", what's next? Chrome hypervisor?
This company has an x86-to-WASM compiler that lets you execute arbitrary binaries in the browser. Also a JVM to WASM transpiler. There's a fantastic Meetup presentation given by one of them where they show running a C++ multiplayer game with both client AND server running in a browser, using WebRTC as a networking polyfill. Really mindblowing: https://youtu.be/7JUs4c99-mo?t=167
Ok, now you have my attention. Been waiting for that possibility for a while!
Earlier quoted context omitted.
It can still be exploited the Applets/Flash way, by forcing the internal memory to become corrupted and with it change its behaviour.
Right, you can corrupt memory and thereby alter behavior, but that memory is a managed array. You can't corrupt anything outside of the application's own memory. As you say, you can change behavior, and thereby do whatever you want with whatever the wasm application is allowed to access. Which is a very limited set of things. Likening it to Java applets or Flash is deceptive -- yes, you can still hack them and exploi…