Scantist Insights | Spring Framework and Log4j Remote Code Execution Vulnerability Impact Analysis
The recent pandemic has catalysed the pace of digital transformation for businesses, resulting in new approaches of security attacks and incidents. This brings about new security requirements that organisations must set up to mitigate the business risks of such events. On one hand, vulnerabilities are constantly mutating and iterating, bringing about more destructive effects to applications. On the other hand, attackers are also constantly looking out for different means of exploit.
As of now, there is still a growing number of organisations and teams who are affected by the log4j vulnerability. The Spring Framework remote attack execution (RCE) vulnerability (CVE-2022-22965) has become the focus of attention in recent weeks. An official version has been released to fix the vulnerability. In accordance to the disclosure of this vulnerability, current practices and statistical data, let us analyse According to the current vulnerability management practices and statistical data, we will analyse the log4j2 and spring-core supply chain vulnerability with third-party libraries that were published on Maven Central.
RCE Vulnerability Impact Analysis
As an important aspect of software composition analysis, we monitor and maintain a knowledge graph of the popular open source libraries used by developers. The data we track includes versions of libraries, publish dates, dependencies and known vulnerabilities of these libraries. As of this moment of writing, the knowledge graph for Maven contains more than 456,000 unique libraries with 8.29 million unique library versions. Due to our extensive database, Scantist is able to fully evaluate the impact of the two vulnerabilities in the spring framework and log4j2 open source components.
According to the latest news, NVD recorded the Spring framework RCE vulnerability (CVE-2022-22965) and rated it as a Critical Vulnerability on March 30th, 2022.
https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement
Scantist SCA has upgraded the database and supports the detection of exploits of CVE-2022-22965. Meanwhile, Scantist’s SCA (Thompson) will provide remediation suggestion to users. Users can scan and analyse all affected projects / source codes with our SCA tools to reduce security risks.
Direct Dependencies
As the most commonly used Java framework, Spring Framework has released a total of 222 evolution versions since its inception. It also released an official patch to the RCE vulnerability. We will analyze the vulnerability’s impact based previously published spring-core versions for reference. The figure below shows the number of the third-party packages which directly depend on spring-core. Most of them have less than 2000 user components except some commonly used packages.
Transitive dependencies
We extended the dependency impact analysis to the previously published versions of spring-core. Shown in the figure below, we found that more than
1.04 million third-party packages depend on spring-core directly or transitively. Those packages take up 12.35% of all the Maven Central packages. Most of these packages dependency are distributed among 1 to 4 distances as shown below, which is differs greatly from log4j-core dependents’ distribution statistics.
After we combined different versions of packages to library-level (as shown in the figure below), the analysis result proves the difference in supply chain positioning between spring and log4j-core, which could be a result of their different functionalities.
As the most important framework of Java development, Spring-core is extensively used by developers. Meanwhile, log4j is one of the most important fundamental component of spring-core that supports the application’s logging functionalities. As a result, software supply chains are extensively dependent on it. Through the navigation of the Log4j2 JDNI RCE vulnerability, most security teams are now more prepared to remediate and patch the Spring-core RCE vulnerability.
Log4j2 is an open source logging component under the Apache foundation and it is extensively used for software development. On Nov 24th 2021, the AliCloud security team reported the Log4j remote attack execution (CVE-2021-44228) vulnerability to the Apache foundation. You may read our previous blog post for more information of the vulnerability and solutions to fix it.
Before the official release of the fixed version log4j-core@2.17.1, a total of 47 versions of log4j2 were released. The figure below shows the number of third-party component versions that directly depend on these 47 log4j-core versions. Log4j-core@2.14.1 is the latest version before the vulnerability was released, while 2.15.0, 2.16.0, and 2.17.0 are the follow-up repair versions after the vulnerability broke out, and the vulnerability was finally fully resolved in 2.17.1 repair. As show in the figure below, 2.13.3~2.14.1 are widely used versions before the vulnerability was disclosed.
Using log4j-core@2.14.1 as an example for analysis, the figure below shows the distribution of dependent packages. X-coordinate represents the dependency distance, for example, A->B->C indicates the dependency distance is 2. From the figure below, most packages’ dependency distances are between 3 to 7.
We analysed the dependency impact of affected packages in log4j-core and the results are illustrated in the graph below. There were 1.58 million third-party packages discovered to be dependent on log4j-core directly or transitively, making up 19.05% of packages on Maven Central. Their dependency distances are distributed between 3 to 7, similar to the dependency distance statistics of log4j-core@2.14.1.
We combined the affected packages versions to its third-party library level and the results are as follow. The blue bars show that there is at least one library dependent on the vulnerability-affected log4j-core in the current dependency distance, while the red histogram shows that the latest versions of dependent library are still dependent on the vulnerability-affected log4j-core. From the figure below, we can find that most of the affected libraries never apply the patch for log4j-core JNDI RCE vulnerability.
Solutions to Software Supply Chain Vulnerabilities
With the recent security exploits surfacing as a result of the vulnerabilities disclosed in log4j and spring framework, security management of software supple chains – from various aspects such as software composition analysis (SCA), fuzzing tools to support binary scans, open source management and open source software analysis has been brought to attention.
Scantist has our proprietary vulnerability database as a result of our extensive research base and expertise, which also allows us to detect and alert users of publicly undisclosed vulnerabilities. We provide unparalleled and comprehensive visibility into your software supply chain with high accuracy of scan results. A vulnerability may exist in different components or different versions of it. Scantist efficiently maps out the vulnerabilities that might exist in your applications with dependency mapping and provide actionable remediation for you to fix them.
Related Blogs
Find out how we’ve helped organisations like you
The Urgent Need for Vigilance in the Software Supply Chain
In an era where digital infrastructure underpins nearly every aspect of our lives, from banking, automotive to healthcare, the integrity of our software supply chain has never been more critical. Recent data from cybersecurity experts paints a stark picture: software supply chain attacks are occurring at an alarming rate of one every two days in 2024. This surge in attacks, targeting U.S. companies and IT providers most frequently, poses a severe threat to national security and economic stability.
