41–50 of 52 posts
Earlier quoted context omitted.
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.
The article claims NASA use Drupal, which was quick to verify as true, but NASA also uses Django, or at least the Django project still claims they do. Why on earth are they using both?
> Why on earth are they using both? You lost the chance for a great pun here.
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.
> 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?!
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.
That article doesn't explain what the WASM code does in Drupal.
I think you missed this paragraph: 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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
> 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 opin…
Earlier quoted context omitted.
I think you missed this paragraph: 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.
So instead of trusting libphp.so, you have to trust mod_wasm.so that is running a php interpreter internally. Is this a win? Genuine question.
- 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.
I used to work with Drupal, it was a security nightmare, like almost all community-based extension system (see also npm). Modules made Drupal popular, they also made it close to impossible to have any sense of security, as only very popular modules would be audited, and you basically needed a panoply of smaller ones depending on your use case. I wonder if that's changed over time, for instance I could see GPT3.5 doin…
1. https://www.drupal.org/drupal-security-team/security-advisor...
Earlier quoted context omitted.
> 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 opin…
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.