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?

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.

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:

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

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.

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

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

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:

Whitelist support in eval, killing Checkpoint's exploit, and forcing the attacker to find an other way to get their payload executed. Automatic generation of whitelist, preventing the introduction of new callsites to dangerous functions, forcing attackers to use only existing sites, à la ret2libc. 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.

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

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.

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

An authentication bypass via type-juggling, mitigated by sp.sloppy_comparison.enable(); , disabled by default because a lot of applications are breaking when type-juggling is disabled.

, disabled by default because a lot of applications are breaking when type-juggling is disabled. A SQL injection, which, like Magento 2's CVE-2019-7139, isn't mitigated in a generic way, yet.

An user enumeration via a timing attack, that can't be mitigated in a generic way.

An arbitrary function call that can't be mitigated in a generic way, since it's a direct call to call_user_func_array with user-controlled parameters.

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.

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

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

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

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

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(); .

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 .

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.

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.

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.

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.

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.