Since the Apache Log4j 2 “alarming vulnerability” was exposed on December 9, many technology companies around the world have been affected by it.
On December 17, Google announced that it had investigated the incident and published the results on the official Google cloud page on December 21.
Google Workspace core services for consumers and paid users do not use Log4j2 and are not affected by the CVE-2021-44228 and CVE-2021-45046 “vulnerabilities,” according to survey results posted on the Google cloud page on Dec. 21. “. For its part, Google said it will provide details of the status of the Workspace core service for this security advisory.
Google said that Google Cloud is actively monitoring the security vulnerabilities in the open source Apache “Log4j 2” utility (CVE-2021-44228 and CVE-2021-45046). They have taken note of the reported Apache “Log4j 1.x” vulnerability (CVE-2021-4104) and recommend that users update to the latest version of Log4j2.
On December 17, on the Google cloud blog page, the Google Open Source Insights Team explained all that they have observed about the Apache Log4J vulnerability. They describe the widespread vulnerability and the current progress in fixing the open source JVM ecosystem.
Google then assessed the potential impact of the vulnerability on Google cloud products and services, and provided real-time updates on the potential impact of the open source Apache “Log4j 2” vulnerability on Google cloud products and services based on ongoing investigations. Google said this will be an ongoing activity and will continue to provide updates through this page and customer communication channels.
Size of Apache Log4j Vulnerability and Impact
It is reported that the previously disclosed Log4j vulnerabilities involve more than 35,000 Java packages, representing more than 8 percent of the Maven Central repository (the repository is the most important Java package repository, which brings extensive results to the software industry). Experts note that 8% is a large value for the entire ecosystem, as the average value of Maven Central advisories results is 2%, with a median of less than 0.1%. Of course, the figures mentioned above do not include all Java packages (such as directly distributed binaries).
In response, experts from Google’s Open Source Insights Team team identified two important issues that hindered the repair process.
One, many packages indirectly depend on log4j. direct dependencies affect about 7,000 pieces of software, in this case any version that depends on the affected version of the Log4j core or Log4j API described in the CVEs (indirect dependencies or pass-through dependencies are self-reliant dependencies).
The staff of all dependencies created a major hurdle in fixing whether to use the dependency necklace view: the deeper the vulnerability was trapped, the more steps it took to fix it. According to the team’s consumer dependency chart, the bar graph results show a significant amount of data. In over 80% of the packages, the vulnerabilities were deeper than one level. In most cases, the affected level dropped by 5 levels (and in some cases by 9 levels). The remediation process needs to go to the deepest dependencies first, and then to all branches.
Second, the dependency resolution algorithm and the ecosystem level selection in the requirements specification conventions. This approach differs from npm, which typically specifies open scopes for dependency requirements (open scopes provide the opportunity to select the latest release that meets the dependency requirements). It then introduces new fixes, where patches are available and users will receive the patched version at the next generation, allowing for faster generation of dependencies.
The Google Open Source Insights Team team said that it is common practice in the Java ecosystem to specify “soft” version requirements - if no other version of the same package appears earlier in the dependency graph, the The exact version used by the parsing algorithm. Propagation fixes typically require explicit action by maintainers to update dependency requirements to patched versions.
With all of this in mind, the Google Open Source Insights Team recommended that the open source community enable automatic dependency updates and add security mitigations. They also provided a list of 500 affected packages, some of which have extremely high deliverability. The experts believe that prioritizing these packages will help with fixes and subsequently remove additional obstacles in the community, and expressed their appreciation to those open source maintainers and consumers who have upgraded their Log4j releases.
The Google Open Source Insights Team team also gave its verdict on how long it will take to fully fix all the issues: it’s hard to know. If all the critical recommendations affecting Maven packages are publicly disclosed, then the process could take a while. The Google team said that less than half (48 percent) of the packages affected by the vulnerability were fixed. But on the Log4j side, about 13 percent have been fixed, and the outlook should be bright.
Incident Review.
On December 9, a vulnerability was exposed in the Apache Log4j2 program, a common component for logging requests, that could compromise systems running Apache Log4J2 version 2.15 or lower and allow an attacker to execute arbitrary code.
On December 10, NIST issued a critical common vulnerability and exposure alert - CVE-2021-4228: The Java Named Directory Interface (JNDI) functionality used in configuration, log messages and parameters does not prevent LDAP and other JNDI-related endpoints from being controlled by an attacker, i.e., an attacker who can control log messages or log message parameters can execute arbitrary code loaded from a remote server when message lookup replacement is enabled.
In the following days, another sensitive data disclosure vulnerability was discovered on Apache Log4j version 2.15.0 that could be used to download data from an affected server, and users were subsequently officially and advised to upgrade to 2.16.0 as soon as possible.
On December 18, Apache Log4j was also exposed to CVE-2021-45105 – Apache Log4j versions 2.0-alpha1 through 2.16.0 do not prevent uncontrolled recursion of self-referential lookups (Apache has officially released version 2.17.0 (Fixed).