Nop’ing function execution

[WhiteWinterWolf]

I miss the ability to nop the execution of functions.

I've read the issue #323 and the FAQ, here is my take on the raised concerns:

What should the return value of a nop’ed function be?

The return value should be variable.

Here is a concrete example of what I mean and miss:

sp.disable_function("chmod").return(TRUE);
sp.disable_function("error_reporting").return(24575);

It would add confusion between drop, nop and log.

It is a already a widely used practice in firewall rules (and a lot of other filtering software) to have allow, drop, and return actions, maybe I miss something but I don't get why it would be specifically more confusing in Snuffleupagus case.

According to Snuffleupagus own documentation, a specific configuration syntax has been chosen to allow maximum flexibility and rules customization is intended for technically-literate users who should be able to distinguish between "returning" a value and "droping" the execution flow.

Usually, when a specific function is called, either it’s a dangerous one and you want to stop the execution immediately, or you want to let it continue and log it. There isn’t really any middle-ground, or at least we failed to find any.

Some web application frameworks and addons may by default call some functions "for our own good" while we have already taken care of everything and, at the same, want to keep malware from relying on the same functions for nefarious purposes. These are not dangerous functions per-se, but their effect can be used to prepare malicious actions we want to avoid.

A good example is the error_reporting(), used by malware as it allows to disable error logging (bypassing btw any control made on ini_set() or through php_admin_value) but this function is also called on startup by WordPress.

For now I have only two possibilities:

• Allow malware to call the error_reporting() function.
• Patch WordPress and its plugins after each update to disable each and every call to this function (and others falling in the same category).

I miss the third option which would be to allow anyone call this function but make it inoperative : legitimate webapps would run happily, while attackers' next step will most likely trigger an alarm.

For the sake of completeness, error_reporting() is just an example. I could also talk about chmod(), used by legitimate apps to reduce the rights on some files, used by malicious ones to make them executable, writable, or anything else.

[jvoisin]

This would add a bit of complexity in our virtual-patching machinery, since we would also need to handle not only the values but the types of the return values.

I think that at some point, @blotus had a fun prototype for replacing functions via virtual patching.

Your usecase for nop can already be fulfilled with the current actions: only allow error_reporting to be called from the corresponding wordpress file. This can even be automated with this script.

[WhiteWinterWolf]

since we would also need to handle not only the values but the types of the return values

I understand, precisely why I chose those two examples ;) .

This can even be automated with this script.

Thanks for the tip. I indeed saw it mentioned somewhere but did not pursue my investigations in this direction, I will do it ASAP :) .

[WhiteWinterWolf]

A potential alternative could be use different functions depending on the data type:

sp.disable_function("chmod").return_bool(TRUE);
sp.disable_function("error_reporting").return_int(24575);

[WhiteWinterWolf]

Your usecase for nop can already be fulfilled with the current actions: only allow error_reporting to be called from the corresponding wordpress file. This can even be automated with this script.

Another benefit from nop'ing functions is the availability to enforce a local policy (somewhat like a Mandatory Access Control).

For instance, I'm confident that I've chosen the right log level, umask and files permissions and I don't want any webapp or plugin to tamper with them, either because they their dev felt like they know better, or because an attacker is relying on a legitimate feature to achieve a malicious activity (see #387 for instance).

Nop'ing the functions allows to keep the webapps as-is while effectively protecting against such threats. Files whitelists do not provide such protection.