Artificial truth

The more you see, the less you believe.

[archives] [latest] | [homepage] | [atom/rss]

Snuffleupagus versus recent high-profile vulnerabilities
Mon 01 July 2019 — download

According to Halvar Flake's's laws, exploit mitigations are only useful if they, at least:

  • Have a clear threat model;
  • Don't add a crazy lot of complexity/significantly hinder performances/make everything undebuggeable;
  • Render a couple of real-world past bugs unexploitable.

Snuffleupagus being almost 2 years old, it's time to look back and check if the project is doing a decent job. If it does not, all its hardening mechanisms should be removed, to only keep the virtual-patching capability.

  • The threat model is laid out in the documentation
  • Regarding complexity, Snuffleupagus is around 4400 lines of (clean) C code, with a coverage close to 100%, and its configuration is as straightforward as it could be. We tested its syntax by making a pool of sysadmin and devops write some rules, and we didn't get a single complain. Nobody opened a single issue on our bugtracker about it.
  • Performance-wise, it doesn't have a measurable impact
  • Debugeability isn't hindered: Snuffleupagus logs every disruptive action it takes, along with the line number, the file name and can even dump the whole request if wanted: if it detects something, it will tell you precisely where, when and why.

So the only remaining question is: Does it kill vulnerabilities?

Drupal 7 and 8 — RCE — CVE-2019-6338 and CVE-2019-6339

SA-CORE-2019-001 and SA-CORE-2019-002, also known as CVE-2019-6338 and CVE-2019-6339 are two remote code executions in Drupal, achieved via phar-based deserialisation.

Snuffleupagus ships with a rule to block this vector, although it's not enabled by default since some people do need to use the phar:// wrapper.

The one-liner to kill this class of vulnerability is sp.wrappers_whitelist.list("php");. It has the nice side-effect of killing other ones that could be reached via other stream wrappers.

Magento 2 — RCE

Daniel Le Gall from SCRT published an RCE for Magento 2. While it can be trivially virtual-patched, it is already blocked by the two enabled-by-default mitigations:

  1. sp.readonly_exec.enable();, preventing writeable files from being executed.
  2. sp.upload_validation.script("your_script.py").enable();, detecting if uploaded files contains valid PHP code, and if they do, aborting the execution.

Drupal 8 — RCE — CVE-2019-6340

SA-CORE-2019-003 is an unserialize-based remote code execution. Snuffleupagus provides a generic mitigation against this kind of attacks: sp.unserialize_hmac.enable(), preventing unauthenticated payloads from being unserialized.

This mitigation is commented in the default configuration file, since it might break websites that stored serialized content before enabling this feature, although the simulation mode can be used to seamlessly update the data, before enabling the mitigation in drop mode.

Horde — Arbitrary file upload — CVE-2019-9858

Ratiosec found an arbitrary file upload in Horde, mitigated exactly like Daniel Le Gall's Magento 2 RCE:

  1. sp.readonly_exec.enable();, preventing writeable files from being executed.
  2. sp.upload_validation.script("your_script.py").enable();, detecting if uploaded files contain PHP code, and if they do, abort the execution.

Drupal — RCE — CVE-2018-7600

SA-CORE-2018-002 is a remote code execution, via an interesting vector (see Checkpoint's analysis for more details). Snuffleupagus doesn't come with generic mitigations to make this vulnerability unexploitable, but it still has some interesting/fun counter-measures to catch the kiddies:

  1. Whitelist support in eval, killing Checkpoint's exploit, and forcing the attacker to find an other way to get their payload executed.
  2. Automatic generation of whitelist, preventing the introduction of new callsites to dangerous functions, forcing attackers to use only existing sites, à la ret2libc.
  3. Basic parameters filtering for system and its friends, making it harder to get code execution with a single request.

While it shouldn't take much time to a serious attacker to walk around those mitigations, this will likely stop some kiddies.

Magento 2 - SQLI — CVE-2019-7139

Charles Fol from ambionics found an unauthenticated SQL injection in Magento2. Unfortunately, Snuffleupagus doesn't have a publicly available generic anti-SQLI feature.

Prestashop — Privesc — CVE-2018-13784

Charles Fol, again, from ambionics disclosed a privilege escalation in Prestashop, via an attack on the insecure cryptographic mechanism used by Prestashop to handle sessions.

Snuffleupagus' cookie encryption features not only prevents stolen cookies from being used, but also ensure their integrity, preventing this attack.

GLPI — A bit of everything — CVE-2019-10231, CVE-2019-10233 and CVE-2019-10477

Julien Szlamowicz, Thomas Chauchefoin and Damin Picard, from Synacktiv recently dumped a couple of GLPI vulnerabilities:

Wordpress — RCE — CVE-2019-8942

Simon Scannell from RIPS found a path traversal and a local file inclusion in WordPress, leading to a remote code execution.

The path traversal isn't prevented by Snuffleupagus, since they can't be distinguished from legitimate usages.

However, the LFI is prevented by sp.readonly_exec.enable();, denying writeable files from being executed by PHP. The second layer of defense, sp.upload_validation.script("your_script.py").enable();, to detect whether uploaded files contain PHP code, might be bypassed: The GD library used to process the images will compress them after they've been uploaded, allowing an attacker to hide their backdoor from Snuffleupagus, only to have it available after decompression.

Wordpress — CSRF → XSS → RCE — CVE-2019-9787

Simon Scannell from RIPS found a Cross-Site Request Forgery in Wordpress, leading to an XSS and can be escalated to an RCE.

The CSRF is mitigated by the SameSite marking feature of Snuffleupagus, while the XSS isn't, and well, since RCE when you're admin is a Wordpress feature, there is little nothing we can do to prevent it without completely breaking Wordpress :P

phpBB — RCE — CVE-2018-19274

Simon Scannell from RIPS disclosed a phar://-based unserialize remote code execution in phpBB, mitigated by the wrapper whitelist feature of Snuffleupagus.

WooCommerce — RCE — CVE-2018-20714

Simon Scannell from RIPS found a logic-based remote code execution in WooCommerce, that can't be generically prevented.

Pydio — RCE — CVE-2018-20718

Simon Scannell and Robin Peraglie from RIPS reported a remote code execution via unserialize in Pydio, mitigated by sp.unserialize_hmac.enable().

Moodle — RCE — CVE-2018-1133

Robin Peraglie from RIPS disclosed a RCE via eval injection in Moodle. This can be mitigated via the eval whitelist feature, with something like sp.eval_whitelist.list().simulation();.

Prestashop — RCE — CVE-2018-20717

Robin Peraglie from RIPS reported an unserialize-based remote code execution, mitigated by sp.unserialize_hmac.enable(), just like CVE-2019-6340 and CVE-2018-20718.

SPIP — RCE — CVE-2019-11071

g0uZ burned a cool RCE in SPIP. The root cause lies in a creative sessions handling, and while this can trivially be virtual-patched in various ways, there is unfortunately no generic mitigation that could prevent the RCE from being exploitable without completely breaking SPIP.

Magento2 — XSS to RCE

Simon Scannell from RIPS found a stored XSS to RCE in Magento 2. The XSS isn't mitigated, but the RCE is, but the wrapper whitelist.

Drupal — Authentication bypass — CVE-2019-6342

Reported by Dave Botsch, the authentication bypass, SA-CORE-2019-008, is a logic bug : Snuffleupagus can't do anything against this in a generic way, but can trivially virtual patch it.

TYPO3 — XSS to RCE — CVE-2019-12748 and CVE-2019-12748

Robin Peraglie from RIPS reported a deserialization-based remote code execution, mitigated by sp.unserialize_hmac.enable(). The XSS relies on insufficient sanitization during the handling of a TYPO3-specific pseudo-scheme to create URL (t3://), which is out of scope of Snuffleupagus' mitigations.

Conclusion

The only vulnerabilities that weren't killed are either:

  • Logic issues, that can't be generically mitigated.
  • Client-side issues, like XSS, that are explicitly out of scope.
  • Application-specific issues that can't be dealt with in a generic way.
  • SQLI, since I'd like this feature to remain private for now.

It seems that Snuffleupagus is doing a decent job!

Feel free to send me an email if you have other cool vulnerabilities that you would like to be added to this article.