3 ms·

PHP was compiled into WASM, so now you can run PHP apps "as WASM". How is this different from just running PHP, without WASM? Apparently it's faster, but also t

PHP was compiled into WASM, so now you can run PHP apps "as WASM". How is this different from just running PHP, without WASM? Apparently it's faster, but also they make this claim: "Picture running Wordpress and not having to worry about attackers breaking into your system" uh, so, you sprinkled some WASM magic on some code and suddenly several decades worth of security research is obsolete? .....yeah, I'm gonna call bullshit. Compiling code or "running in a sandbox" does not stop attackers from breaking into your system. Might slow them down for a few months while they develop some new attacks.

kristjansson 4y ago
edit: this was completely wrong, TFA is talking about server side WASM I think the point is that a simple-enough application can be delievered as WASM and run entirely in the user's browser, so there wouldn't be any server-side system to break into? So one could ship e.g. wordpress + db + content in one bundle, and the user would be none the wiser. A wild claim, and probably self-defeating for anyone who needs to protect their content. Otherwise, the WASM-dust at best moves the security boundry to a different service.
- ThePhysicist 4y ago
  I don't think that's what they mean, Wordpress is a server-side app with a database backend, I don't think you'd want to ship your entire Wordpress database to the browser.
- jeremyjh 4y ago
  No, CGI is an interface for backend web servers, this is not about client code.
- noahtallen 4y ago
  It’s already been done! https://make.wordpress.org/core/2022/09/23/client-side-webassembly-wordpress-with-no-server/ https://make.wordpress.org/core/2022/09/23/client-side-webas... (By my colleague Adam!) I think this experiment becomes interesting thinking about times you really want WordPress to be headless (like demoing a plug-in or theme), but less for serving websites to people. Potentially also useful as a testing development environment. I was surprised at how fast it is, since it basically becomes an SPA.
PoignardAzur 4y ago
Compiling a service to wasm to protect it "from itself" (ie from untrusted data) has trade-offs. On the one hand, you lose ASLR and other security features designed for native code. On the other hand, your program becomes immune to stack smashing, so arbitrary code execution becomes a lot harder for an attacker (at least that's my understanding).
- eyberg 4y ago
  Does it become harder or easier? #include <stdio.h> #include <string.h> int bad(char* src) { int admin = 0; char buf[2]; strcpy(buf, src); printf("%d\n", admin); return admin; } int main() { if (bad("ADMIN!!!")) { printf("we're admin!\n"); } else { printf("we are not admin\n"); } }
  - cstrahan 4y ago
    If you’re worried about securing server side resources by hardening the client side, you’re doing something wrong. At any rate, the example you give is arguably a better case than what we have right now with JS — anyone interested in subverting client side access policies can poke around trivially in the JS globals, they don’t even need to decompile anything, they have a DOM inspector and a REPL to make exploits that much easier to pull off. If security through obscurity is your thing, compiling to WASM could only help. Again, though, client side shenanigans shouldn’t be of any concern anyway. Edit: I thought I was replying to the other comment you made within the context of client side execution, but I can touch on that too. Programming errors (and resulting exploits) aren’t something unique to WASM, and there’s nothing stopping you from using something like Go or Haskell or Rust as a source language, if you want something more safe than C.
- kllrnohj 4y ago
  The fact that the address space starts at 0x0 comboned with no ASLR seems like some pretty major regressions in security. Nearly all SIGSEGV crashes just became memory corruption bugs, for example. That's huge. And of course WASM won't protect from just regular ol logic bugs like SQL injection or similar. Compiling things to WASM to make them "more secure" seems bonkers backwards. WASM's priorities are to protect the host, not the guest.
jeroenhd 4y ago
The WASM sandbox is a lot stricter than running native code, or many other VMs (Java/dotnet). The difference seems to be in the design process: most normal VMs are built around the idea of quickly developing and deploying an application that can do everything a native application can do, without having to deal with platform differences. WASM was built around optimizing specific parts of web pages and was explicitly designed NOT to have a huge surface area. By default, you set it up to be little more than "memory goes in, memory comes out" without having to worry about file system restrictions or sockets like you have to with alternative VMs. I'm not a fan on the way these features are being tacked back onto the runtime, but the approach of having to opt into them make the security boundary a lot more transparent. By disabling the file system (i.e. baking a fake one into memory) you can prevent whole classes of attacks. You won't get surprised by your logging library making network calls (log4j) if your sandbox never even enabled networking in the first place. I'd much rather see easy and safe alternatives (like using containerization APIs) but there's still no easy way to tell your computer "run this program with a maximum amount of memory, CPU time, no network access and no file system outside this directory" that doesn't come with tons of caveats for preventing escape. For PHP, setting up a secure systemd configuration (more secure than the one that comes with your package manager) can be done, but it's still far from easy.
anuraaga 4y ago
> Compiling code or "running in a sandbox" does not stop attackers from breaking into your system. Correct - PHP is a scripting language with managed memory, quite different from C. Probably not all, but most WordPress vulnerabilities have to do with issues like sql injection, bad configuration defaults, etc, all in business logic. All of these will continue to exist when compiled to Wasm. Assuming you actually have access to a database in the first place, while wasmer may have some vendor locked in solutions for it, generally with Wasm you won't get beyond SQLite for the near term.

kristjansson 4y ago

edit: this was completely wrong, TFA is talking about server side WASM I think the point is that a simple-enough application can be delievered as WASM and run entirely in the user's browser, so there wouldn't be any server-side system to break into? So one could ship e.g. wordpress + db + content in one bundle, and the user would be none the wiser. A wild claim, and probably self-defeating for anyone who needs to protect their content. Otherwise, the WASM-dust at best moves the security boundry to a different service.

ThePhysicist 4y ago
I don't think that's what they mean, Wordpress is a server-side app with a database backend, I don't think you'd want to ship your entire Wordpress database to the browser.
jeremyjh 4y ago
No, CGI is an interface for backend web servers, this is not about client code.
noahtallen 4y ago
It’s already been done! https://make.wordpress.org/core/2022/09/23/client-side-webassembly-wordpress-with-no-server/ https://make.wordpress.org/core/2022/09/23/client-side-webas... (By my colleague Adam!) I think this experiment becomes interesting thinking about times you really want WordPress to be headless (like demoing a plug-in or theme), but less for serving websites to people. Potentially also useful as a testing development environment. I was surprised at how fast it is, since it basically becomes an SPA.

PoignardAzur 4y ago

Compiling a service to wasm to protect it "from itself" (ie from untrusted data) has trade-offs. On the one hand, you lose ASLR and other security features designed for native code. On the other hand, your program becomes immune to stack smashing, so arbitrary code execution becomes a lot harder for an attacker (at least that's my understanding).

eyberg 4y ago
Does it become harder or easier? #include <stdio.h> #include <string.h> int bad(char* src) { int admin = 0; char buf[2]; strcpy(buf, src); printf("%d\n", admin); return admin; } int main() { if (bad("ADMIN!!!")) { printf("we're admin!\n"); } else { printf("we are not admin\n"); } }
- cstrahan 4y ago
  If you’re worried about securing server side resources by hardening the client side, you’re doing something wrong. At any rate, the example you give is arguably a better case than what we have right now with JS — anyone interested in subverting client side access policies can poke around trivially in the JS globals, they don’t even need to decompile anything, they have a DOM inspector and a REPL to make exploits that much easier to pull off. If security through obscurity is your thing, compiling to WASM could only help. Again, though, client side shenanigans shouldn’t be of any concern anyway. Edit: I thought I was replying to the other comment you made within the context of client side execution, but I can touch on that too. Programming errors (and resulting exploits) aren’t something unique to WASM, and there’s nothing stopping you from using something like Go or Haskell or Rust as a source language, if you want something more safe than C.
kllrnohj 4y ago
The fact that the address space starts at 0x0 comboned with no ASLR seems like some pretty major regressions in security. Nearly all SIGSEGV crashes just became memory corruption bugs, for example. That's huge. And of course WASM won't protect from just regular ol logic bugs like SQL injection or similar. Compiling things to WASM to make them "more secure" seems bonkers backwards. WASM's priorities are to protect the host, not the guest.

jeroenhd 4y ago

The WASM sandbox is a lot stricter than running native code, or many other VMs (Java/dotnet). The difference seems to be in the design process: most normal VMs are built around the idea of quickly developing and deploying an application that can do everything a native application can do, without having to deal with platform differences. WASM was built around optimizing specific parts of web pages and was explicitly designed NOT to have a huge surface area. By default, you set it up to be little more than "memory goes in, memory comes out" without having to worry about file system restrictions or sockets like you have to with alternative VMs. I'm not a fan on the way these features are being tacked back onto the runtime, but the approach of having to opt into them make the security boundary a lot more transparent. By disabling the file system (i.e. baking a fake one into memory) you can prevent whole classes of attacks. You won't get surprised by your logging library making network calls (log4j) if your sandbox never even enabled networking in the first place. I'd much rather see easy and safe alternatives (like using containerization APIs) but there's still no easy way to tell your computer "run this program with a maximum amount of memory, CPU time, no network access and no file system outside this directory" that doesn't come with tons of caveats for preventing escape. For PHP, setting up a secure systemd configuration (more secure than the one that comes with your package manager) can be done, but it's still far from easy.

anuraaga 4y ago

> Compiling code or "running in a sandbox" does not stop attackers from breaking into your system. Correct - PHP is a scripting language with managed memory, quite different from C. Probably not all, but most WordPress vulnerabilities have to do with issues like sql injection, bad configuration defaults, etc, all in business logic. All of these will continue to exist when compiled to Wasm. Assuming you actually have access to a database in the first place, while wasmer may have some vendor locked in solutions for it, generally with Wasm you won't get beyond SQLite for the near term.