Hello,
The log4j2 vulnerability (CVE-2021-44228) being a hot topic these days, we were also interested internally to understand how SonarQube could help.
SonarQube can’t detect the vulnerability in itself when analyzing just the log4j2 code because it’s a library which by definition doesn’t contain any user input.
SonarQube can detect if a user input reaches a log4j2 API such as logger.info(tainted) and raise a RCE vulnerability issue. For that, you need to use the following custom configuration (only available with SonarQube Enterprise Edition+):
{
"sinks": [
{
"methodId": "org.apache.log4j.Category#",
"isMethodPrefix": true,
"interval": {
"fromIndex": 1
}
},
{
"methodId": "org.apache.logging.log4j.Logger#",
"isMethodPrefix": true,
"interval": {
"fromIndex": 1
}
}
]
}
When scanning the vulnerable app GitHub - christophetd/log4shell-vulnerable-app: Spring Boot web application vulnerable to CVE-2021-44228, nicknamed Log4Shell. with the above configuration as parameter of the scan with -Dsonar.security.sinks.javasecurity.S5334=./log4jmethodids.json, you get the expected vulnerability:
This configuration will generate FPs in case you are already using the latest patched version of log4j2.
Now, even if you detect such problems in your code, the mitigation would be painful to put in place. You’d need to update your code like this:
logger.info("%m{nolookups}", tainted);
Overall, the best solution is to upgrade your dependency to the latest patch provided by the Apache Log4j people (2.12.2 or 2.16 as of writing).
Alex