4 ms·

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 des

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.
0xbadcafebee 4y ago
But arbitrary code execution hardly features on the OWASP Top 10 for 2021: - Broken Access Control - Cryptographic Failures - Injection - Insecure Design - Security Misconfiguration - Vulnerable and Outdated Components - Identification and Authentication Failures - Software and Data Integrity Failures - Security Logging and Monitoring Failures - Server-Side Request Forgery If a modern hacker wants to exploit a web app, their first thought isn't shellcode.

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.

0xbadcafebee 4y ago

But arbitrary code execution hardly features on the OWASP Top 10 for 2021: - Broken Access Control - Cryptographic Failures - Injection - Insecure Design - Security Misconfiguration - Vulnerable and Outdated Components - Identification and Authentication Failures - Software and Data Integrity Failures - Security Logging and Monitoring Failures - Server-Side Request Forgery If a modern hacker wants to exploit a web app, their first thought isn't shellcode.