Google announced Log4j 2 "vulnerability" investigation results: not affected | Google Workspace core services did not use Log4j 2

Since the Apache Log4j 2 "shocking vulnerability" was exposed on December 9, many global technology companies 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.

According to the survey results published on the Google cloud page on December 21, the core service of Google Workspace for consumers and paying users does not use Log4j2, nor is it affected by the CVE-2021-44228 and CVE-2021-45046 "vulnerabilities". Google said it will provide detailed status of core services in the workspace for this security consultation.

Google said that Google Cloud is actively paying attention to security vulnerabilities in the open source Apache "Log4j 2" utility (CVE-2021-44228 and CVE-2021-45046). They have noticed the reported Apache "Log4j 1.x" vulnerability (CVE-2021-4104) and recommend that users update to the latest version of Log4j2.

On December 17th, on the Google cloud blog page, the Google Open Source Insights Team explained all their observations about Apache Log4J vulnerabilities. They described widespread vulnerabilities and current progress in fixing the open source JVM ecosystem.

Subsequently, Google 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 the results of the ongoing investigation. Google said that this will be an ongoing event and will continue to provide updates through this page and customer communication channels in the future.

The scale and impact of Apache Log4j vulnerabilities

It is reported that the previously disclosed Log4j vulnerabilities involved more than 35,000 Java packages, accounting for more than 8% of the Maven central repository (the repository is the most important Java package repository, which has brought extensive results to the software industry). Experts pointed out that for the entire ecosystem, 8% is a large value, because the average value of Maven Central advisories results is 2%, and the median is less than 0.1%. Of course, the numbers mentioned above do not include all Java packages (such as binary files that are distributed directly).

In response, experts from the Google Open Source Insights Team team pointed out two important issues that hindered the repair process:

1. Many software packages indirectly depend on log4j. There are about 7000 direct dependencies affected software. In this case, any version depends on the affected version of Log4j core or Log4j API described in CVEs (indirect or transitive dependencies refer to self-dependent dependencies).

The staff of all dependencies created a major obstacle when repairing whether to use the dependency necklace to check: the deeper the loophole, the more steps to repair it. According to the team's consumer dependency graph, the histogram result shows a lot of data. In more than 80% of software packages, the depth of the vulnerability exceeds one level. In most cases, the affected level dropped by 5 levels (some even dropped by 9 levels). The repair process needs to go to the deepest dependency first, and then to all branches.

Second, rely on the analysis algorithm and the ecosystem-level selection in the requirement specification agreement. This approach is different from npm, which usually specifies an open range for dependent requirements (the open range provides an opportunity to choose the latest released version that meets the dependent requirements). Subsequently, it introduced a new repair plan. After the patch is available, users will receive the patched version in the next build, and the dependencies can be generated faster.

The Google Open Source Insights Team said that in the Java ecosystem, it is common practice to specify "soft" version requirements-if no other versions of the same package appear in the dependency graph, the exact version used by the parsing algorithm. Propagating fixes usually requires maintainers to take clear actions to update dependency requirements to patched versions.

With the above, 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 are extremely deliverable. Experts believe that prioritizing these packages will help the repair work, and then remove more obstacles in the community, and expressed gratitude to those open source maintainers and consumers who upgraded the Log4j version.

As for how long it will take to completely fix all the problems, the Google Open Source Insights Team also gave its own judgment: it is difficult to know. If all the key recommendations affecting Maven packages are publicly disclosed, then this process may take a while. The Google team stated that less than half (48%) of the software packages affected by the vulnerability have been fixed. But in Log4j, about 13% of the problems have been resolved, and the prospects should be bright.

Event review:

On December 9, a vulnerability was revealed in the Apache Log4j2 program, a common component used to log requests. The vulnerability could damage systems running Apache Log4J2 version 2.15 or lower and allow attackers 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) function used in configuration, log messages, and parameters cannot prevent attackers from controlling LDAP and others JNDI related endpoints, that is, when message search and replacement is enabled, an attacker who can control log messages or log message parameters can execute arbitrary code loaded from a remote server.

In the following days, it was discovered that there was a vulnerability of sensitive data leakage in Apache Log4j version 2.15.0, which can be used to download data from the affected server. Then the official recommends that users upgrade to 2.16.0 as soon as possible.

On December 18th, Apache Log4j was exposed to CVE-2021-45105 vulnerability-Apache Log4j 2.0-alpha1 to 2.16.0 version cannot prevent uncontrolled recursion of self-reference search (Apache officially released version 2.17.0 fix) .