Spring4Shell Vulnerability vs Log4Shell Vulnerability

On March 29, 2022, details of a zero-day vulnerability in Spring Framework (CVE-2022-22965) were leaked. For many, this is reminiscent of the zero-day vulnerability in Log4j (CVE-2021-44228) back in December 2021.

What is the difference between the vulnerabilities?

The Spring Framework vulnerability was caused by unforeseen access to Tomcat’s ClassLoader as a result of the new Module feature added in Java 9. The access could potentially allow an attacker to write a malicious JSP file accessible via the application server.

On the other hand, the Log4j vulnerability was the result of an exploitable logging feature. If the logging feature is successfully exploited on your infrastructure, attackers can perform an RCE (Remote Code Execution) attack and compromise the affected server.

What is the scope of the vulnerabilities?

Since we are a cloud-based Software Composition Analysis (SCA) provider, we are able to leverage data on the scope of the vulnerabilities.

As we mentioned in December, 95 percent of our enterprise customers – organizations with over 100 applications – use Java. Of those enterprise customers using Java, 88 percent use some version of Log4j, the most popular being version 1.2.

When it comes to Spring Framework, we found that 55 percent of Java applications leverage some form of Spring Beans, most using version 5.3.

So how many enterprise customers using Java leverage vulnerable versions of Log4j or Spring Beans? Well, for Log4j, we found that 58 percent are using a vulnerable version. For Spring Beans, the number is higher, 89 percent. One reason that the number is higher for Spring Beans is because older, non-vulnerable versions of Spring Beans (eg, version 2.x) are rarely used anymore. However, older, non-vulnerable versions of Log4j (eg, version 1.2) were still commonly used at the time of that CVE disclosure.

Spring bean vs Log4j

What’s the takeaway? If you are a Java customer using Spring Beans, chances are, you’re using a vulnerable version. However, unlike Log4j which was trivial to exploit in nearly all circumstances, the Spring vulnerability is not exploitable unless a number of conditions are also met (outlined in our blog post). So even though the Spring vulnerability affects more customers overall, Log4j was more susceptible to mass exploitation.

What should I do now?

While log4j was a “drop everything and patch now” type of event, we can take a more measured approach with the Spring vulnerability. If your application does not meet all the conditions to be exploitable, you should still plan to patch soon – as you should for any vulnerable library – but you do not need to do so immediately.

We also advise the use of Veracode Software Composition Analysis. With Veracode SCA, you can quickly verify whether an application portfolio that you’re scanning with us contains the library needed to be affected by either of these vulnerabilities.

If you are an existing Veracode customer but do not have SCA, please contact your Veracode representative for more information on a 10-day courtesy license.

For the latest information on the Spring Framework vulnerability, please check out our blog,
Spring Framework Remote Code Execution (CVE-2022-22965). For the latest information on Log4j vulnerability, please bookmark our resources page.

Source

On March 29, 2022, details of a zero-day vulnerability in Spring Framework (CVE-2022-22965) were leaked. For many, this is reminiscent of the zero-day vulnerability in Log4j (CVE-2021-44228) back in December 2021.

What is the difference between the vulnerabilities?

The Spring Framework vulnerability was caused by unforeseen access to Tomcat’s ClassLoader as a result of the new Module feature added in Java 9. The access could potentially allow an attacker to write a malicious JSP file accessible via the application server.

On the other hand, the Log4j vulnerability was the result of an exploitable logging feature. If the logging feature is successfully exploited on your infrastructure, attackers can perform an RCE (Remote Code Execution) attack and compromise the affected server.

What is the scope of the vulnerabilities?

Since we are a cloud-based Software Composition Analysis (SCA) provider, we are able to leverage data on the scope of the vulnerabilities.

As we mentioned in December, 95 percent of our enterprise customers – organizations with over 100 applications – use Java. Of those enterprise customers using Java, 88 percent use some version of Log4j, the most popular being version 1.2.

When it comes to Spring Framework, we found that 55 percent of Java applications leverage some form of Spring Beans, most using version 5.3.

So how many enterprise customers using Java leverage vulnerable versions of Log4j or Spring Beans? Well, for Log4j, we found that 58 percent are using a vulnerable version. For Spring Beans, the number is higher, 89 percent. One reason that the number is higher for Spring Beans is because older, non-vulnerable versions of Spring Beans (eg, version 2.x) are rarely used anymore. However, older, non-vulnerable versions of Log4j (eg, version 1.2) were still commonly used at the time of that CVE disclosure.

Spring bean vs Log4j

What’s the takeaway? If you are a Java customer using Spring Beans, chances are, you’re using a vulnerable version. However, unlike Log4j which was trivial to exploit in nearly all circumstances, the Spring vulnerability is not exploitable unless a number of conditions are also met (outlined in our blog post). So even though the Spring vulnerability affects more customers overall, Log4j was more susceptible to mass exploitation.

What should I do now?

While log4j was a “drop everything and patch now” type of event, we can take a more measured approach with the Spring vulnerability. If your application does not meet all the conditions to be exploitable, you should still plan to patch soon – as you should for any vulnerable library – but you do not need to do so immediately.

We also advise the use of Veracode Software Composition Analysis. With Veracode SCA, you can quickly verify whether an application portfolio that you’re scanning with us contains the library needed to be affected by either of these vulnerabilities.

If you are an existing Veracode customer but do not have SCA, please contact your Veracode representative for more information on a 10-day courtesy license.

For the latest information on the Spring Framework vulnerability, please check out our blog,
Spring Framework Remote Code Execution (CVE-2022-22965). For the latest information on Log4j vulnerability, please bookmark our resources page.

Source

More from author

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Related posts

Advertismentspot_img

Latest posts

Senators Urge FTC to Probe ID.me Over Selfie Data – Krebs on Security

Some of more tech-savvy Democrats in the U.S. Senate are asking the Federal Trade Commission (FTC) to investigate identity-proofing company ID.me for “deceptive statements”...

Personal Information of Nearly Two Million Texans Exposed

The personal information of nearly two million Texans was exposed for nearly three years due to a programming issue at the Texas Department of...

Critical VMware Bug Exploits Continue, as Botnet Operators Jump In

Recently uncovered VMware vulnerabilities continue to anchor an ongoing wave of cyberattacks bent on dropping various payloads. In the latest spate of activity,...

Want to stay up to date with the latest news?

We would love to hear from you! Please fill in your details and we will stay in touch. It's that simple!