Actually, that is one of the Wasm key features: being a platform-independent binary not tied to any specific HW architecture.
Translating x86_64 code to arm64 requires more CPU cycles than JITting Wasm into arm64 or x86_64.
Buy even more: in the use case covered in this article, the PHP interpreter won't change so it can be AoT compiled upon deployment to the target architecture. No JIT compilation needed :-)
Does is prevent it, or just limit the arbitrary PHP execution to inside the WASM sandbox? If the latter, that's still helpful, but still leaves quite a few of the typical end goals in place...like altering the content presented to visitors, etc.
yup, PHP RCE inside the PHP WASM sandbox is not much different in scope than PHP RCE inside a drupal apache container more or less - you get RW on the complete drupal instance.
The Apache HTTP server and the Drupal packages remain unchanged. However, instead of loading the libphp.so extension module, it incorporates mod_wasm.so. In addition, instead of relying on the traditional PHP interpreter, it utilizes a PHP build in the WebAssembly binary format.
The biggest gain comes from mod_wasm using a Wasm runtime to run the PHP interpreter in a sandboxed environment. And mod_wasm can be used the same with Python or Ruby, or anything that builds for WebAssembly.
- No errors (even fatal) from the Wasm module will bring down Apache HTTPD.
- mod_wasm's code base is small enough to inspect thoroughly and test thoroughly to ensure it is secure
- Indeed you will now have to trust the embedded Wasm runtime (wasmtime as of today). As a naïve analogy, this is the equivalent of trusting a virtual CPU(Wasm)+OS(WASI), which gets tested in thousands of other scenarios than the ones used in mod_wasm and issues get fixed and corrected asap.
This article explores how Drupal can benefit from the capabilities-based security model offered by WebAssembly, a portable binary format that allows execution of code in a safe and efficient manner. By deploying Drupal within a WebAssembly-based stack, it gains an additional security layer, protecting against a wide range of vulnerabilities, including those that may not be public yet but can be preemptively mitigated through these mechanisms.
> capabilities-based security model offered by WebAssembly
What? Since when does WebAssembly natively ship with a "capabilities-based security model"?
> protecting against a wide range of vulnerabilities, including those that may not be public yet but can be preemptively mitigated through these mechanisms
Not yet public vulnerabilities?
Who was this article/summary written by? Reeks of GPT or at least someone who doesn't actually know the subject very well.
Capabilities based means that by default Wasm cannot do anything with the outside world. You have to explicitly declare the specific access you are giving, for example if the runtime implements WASI filesystem access you need to specify which parts of the underlying filesystem will be accessible to the module
Not yet public means exactly that. You may have a buffer overflow issue in your code that you are unaware of. There are technologies that help mitigate those when/if discovered. Wasm is one of them but not the only one (ie most modern compilers have specific settings to harden the binaries against some issues)
Think in the minimum container you need to run some Python code (>300MB?). Now, compare that to just the Python interpreter compiled into Wasm (25MB). If you need deploy that into different nodes, that's a huge difference.
Also, Wasm modules don't have cold-starts as containers.
Regarding running untrusted code, ask the folks at AWS, Azure or Google Cloud dealing with that...
Translating x86_64 code to arm64 requires more CPU cycles than JITting Wasm into arm64 or x86_64.
Buy even more: in the use case covered in this article, the PHP interpreter won't change so it can be AoT compiled upon deployment to the target architecture. No JIT compilation needed :-)