Hacker News new | ask | show | jobs
by zdragnar 1120 days ago
No outgoing http requests, no ability to connect to an external database such as mysql- only SQLite is used.

No explanation for what vulnerabilities standard Drupal is actually being hardened against.

4 comments

> No explanation for what vulnerabilities standard Drupal is actually being hardened against.

But... Are you not afraid of these unknown, not-yet-public vulnerabilities that this solution clearly protects us against?!

> But... Are you not afraid of these unknown, not-yet-public vulnerabilities that this solution clearly protects us against?!

No, not really. First of all, a heavy disclaimer: I am speaking as a rather cynical, old, downright ancient PHP developer and not in any other capability. Not as a former Drupal security team lead, not as a developer for whatever clients I have, just plain old me.

The biggest threat in my opinion on a properly hosted Drupal is information disclosure and privilege escalation within that Drupal instance. Arbitrary code execution is utterly pointless because the user that runs Drupal will have no privileges and there'll be nothing installed on the host, nothing to run anyways. And guess what, none of that benefits from this WASM sorcery. SQL injection and XSS -- and potentially allowing private files to be downloaded -- is the real problem while this protects from arbitrary code execution.

yes, I think it seems to focus on rce vulnerabilities which in drupal are relatively rare. But also it seems almost like a research project or a work in progress, hence may not be immediately ready for prod? with that said, would be nice if both these things were stated upfront to set the expectations correctly. Like, add "experimental" to the title maybe.
it's not only that rce vulnerabilities are rare, I contend they hardly matter. You should not have anything in your php containers an RCE can run.
(Wasm Labs dev :)) For me, this is the key point. The end goal is to limit the attack surface for future vulnerabilities. This is not something specific to Drupal or PHP, but an example about technologies / apps that can take advantage of Wasm.
Don't disagree - but if I have a limited amount of resources to harden my Drupal server, it might be best to start looking at hardening around the most commonly exploited Drupal vulnerabilities.

Having said that, searching Druapl on the CISA know exploited list shows a number of remote code execution vulnerabilities that this would help mitigate: https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Indeed! As an example, SA-CORE-2020-013 can be mitigated with Wasm. An that one is classified as Critical.
Take a look at the linked article about how some PHP vulnerabilities can be mitigated with WebAssembly: https://wasmlabs.dev/articles/mitigating-php-vulnerabilities...
Yeah, would have been nice to have a list of the last dozen or so medium+ Drupal CVEs and if they were mitigated to any degree by this setup.
SA-CORE-2020-013 is one of them.
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.
We are working on adding all that functionality, explanation here: https://news.ycombinator.com/item?id=36115146
For a different approach that has FastCGI and MySQL support: https://wasmlabs.dev/articles/wordpress-nginx-fcgi-mysql/