kalessil
get_defined_functions() is malware?
| Subject | Details |
|---|---|
| Plugin | Php Inspections (EA Ultimate) v2021.5 |
| Language level | e.g. PHP 7.4 (check project settings or composer.json) |
Question
For any code with get_defined_functions(), I get
[EA] This function looks pretty much as part of some malware.
in "PHP | Php Inspections (EA Ultimate) | Security | Basic malware patterns".
What is wrong with this function? Is there a risk from merely calling it, or do I need to do anything further with the result?
It's not a risk if you're the one that added it in your code. The risk is having it in your code without realizing it. For example, if someone already compromised your system and included arbitrary code (possibly backdoors).
The inspection merely point to that to make sure this is code you recognize
Thanks!
So for any intended use I will put a /** @noinspection PotentialMalwareInspection */.
@ea-inspections-team Is this type of inspection really useful? It seems to me a bit problematic to indicate that this function could possibly belong to malware. Malware is much more complex than a function. And maybe the ideal in this case would be a specific package for this purpose (which maybe even exists). My suggestion would be to at least mark it off by default.
A first step could be a better explanation in the help text.
Ofc any code inserted by others can be compromising, using only innocent-looking functions. So I wonder how useful this really is. Probably an empirical question, with an answer that changes over time (how many real-world hacks will insert specific functions).
Since nobody asked and I can't think of one on top of my head: how does an attack vector look like using this function? I mean it just "Returns an array of all defined functions" (ref).
@kalessil: you have better background in PHP+security stack, can you please share more details on the subject?
@ea-inspections-team:
- @donquixote makes a good point about the message could be better
- For general-purpose applications, usage of the function is rare: there are APIs for checking the existence of methods and functions that are commonly used. The intention behind this inspection is "We are supposed to know what APIs we are going to use; looking up the whole runtime is fishy."
@donquixote: IMO, suppression for the intended usages is the way to go. Also, it would be great to learn how it was used and see if @ea-inspections-team could improve the inspection and the related documentation.
how does an attack vector look like using this function?
I would be interested in that!
it would be great to learn how it was used
I don't remember my own exact use case.
I know of a few places where it is used in Drupal.
The background: In Drupal there is a hook system where a function can respond to an event if the function name matches a given pattern. In some cases, the pattern would allow a wide range of function names, that are too expensive to all discover with function_exists() calls.
E.g. function mymodule_update_N(), where N can be a number like 10014, and mymodule is the name of a module. While the list of module names is known and limited, the numbers are not.
Another would be mytheme_preprocess_HOOK__suffix1__suffix2(), where depending on the hook name, different suffixes can be appended to target very specific scenarios.
The way to find all implementations is to call get_defined_function() and then preg_grep().
We could argue all day long if this is a good system or not, but it has existed since a long time and has not gone away yet.
It is possible that my own use case was when working on this code in Drupal itself, but I don't remember it now.
Another use case would be to detect which additional functions are added when a file is loaded, by comparing get_defined_functions() before and after. This would be quite expensive, so I don't think people would generally do that.
@donquixote: it is more moving pieces, but here is an example of how get_defined_functions might be used as part of CVE and this can be applied to malware.
Additionally, there was some back and forth with addressing access to disabled functions (disabled in PHP config); you can find a pointer here.
And thank you for sharing detailed context!
@donquixote: it is more moving pieces, but here is an example of how get_defined_functions might be used as part of CVE and this can be applied to malware.
There seems to be a long way from calling get_defined_functions() as part of the codebase to this kind of attack, where we have user-provided php code sent to eval(), which is another level of reckless.
The trick seems to be to bypass attempts to detect malicious parts of user-provided php. But, user-provided php is just a bad idea to begin with. And, this attack does not really need the function to be called from within the project's php code.
To me, this scenario is not a convincing reason to raise suspicion on calls to get_defined_functions().
The trick seems to be to bypass attempts to detect malicious parts of user-provided php.
Yes, in the referenced case it's aiming exactly to bypass WAF (Web Application Firewall) and exploit an RCE.
To me, this scenario is not a convincing reason to raise suspicion on calls to get_defined_functions().
I would reframe it as potential to harden context checks for get_defined_functions and at least check if the internal array index is presented in the usage scope. cc @ea-inspections-team
As a possible malware component, it can invoke internal functions by numeric index, and I assume some WAFs or malware scanners will allow remote calls of this sort.