Is there such a thing as Spring4Shell?

Very early in the morning on March 30th (for me), my colleague DeveloperSteve posted a “Hey, have you seen this?” message in our slack channel. It was an “advance warning” of a “probable” remote code execution (RCE) in the massively popular Java Spring framework. I would come to find out that even earlier than that, the Snyk Security team started investigation a potential RCE in Spring after seeing a tweet that has since been deleted.

Details seemed sketchy at best at this point (about 1:20am EDT). There was a tweet with screenshots that had been deleted. There were references to a pull request (PR) that, as it turns out, was first put up on February 18th, but only merged on March 29th.

Various parties were trying to make the nickname “Spring4Shell” stick (or, sometimes just SpringShell), while Spring Core maintainers were adding comments to the PR saying there was no known RCE.

So, just what the heck was going on and what is going on now?

What’s the bottom line (for now)?

There’s a credible RCE vulnerability in spring-beans package, which is part of Spring Core. This is a key enabler of the inversion of control (IoC) capabilities of Spring. This is often referred to as dependency injection.

If you’ve used the @Autowired annotation or utilized the magic of constructor injection, you’ve encountered dependency injection in the Spring ecosystem.

In affected versions, an RCE is achievable by manipulating the ClassLoader via a carefully composed HTTP POST request.

At this time, the exploit is only known to be possible with a Java Runtime Environment (JRE) version 9 or greater AND Tomcat version 9 or greater.

The best immediate remediation is to deploy your application in an older version of the JRE and/or an older version of Tomcat.

We’ll continue to provide updates through our vulnerability database as the situation evolves.

Where is all the confusion coming from?

One of the first blog posts our team was alerted to in the wee hours of March 30th has since been deleted. This post referenced a tweet that was also deleted. Despite the double-delete, there was a verifiable reference to a commit to Spring Core related that is related to deserialization (a Java feature that has led to RCEs before – Log4Shell, anyone?).

The comment on this commit says:

Since SerializationUtils#deserialize is based on Java's serialization
mechanism, it can be the source of Remote Code Execution (RCE)
vulnerabilities.

As the day progressed, there was more buzz (with very little verifiable fact to back it up) that we might be dealing with an RCE in Spring Core.

Further down in the comments, a Spring Core committer validated another comment stating that this commit had nothing to do with any known RCE.

And, in fact, if you look at the PR the commit resolves, it was first opened on February 18th.

Now, here’s the kicker: while all this was going on, the Interwebs was busy conflating this evolving issue with another known issue in a completely different project: Spring Cloud Function. So as to not further this confusion, I won’t go into the details of this vulnerability. Suffice it to say that if you’re reading something on vulnerabilities in Spring Cloud, you’re barking up the wrong tree for information on Spring4Shell (please, can we give it a different name?)

So, what is Spring4Shell after all?

Stay tuned

We’ll be updating this blog as we learn more about Spring4Shell (last update: March 31, 2022)

Out of an abundance of caution and not wanting to act on incomplete information, security researchers at Snyk spent time reviewing the situation over the course of the day on March 30th.

At this time, our conclusion is that there’s a credible RCE threat in the Spring Core spring-beans package. For better or worse, Spring4Shell is sticking. It makes sense as there’s already a legitimate Spring Shell project in the Spring ecosystem.

Spring4Shell remediation

A new version of the Spring Framework has been released that the current exploit does not work on. It’s version 5.2.20.

And, if you work with Spring Boot, just today version 2.5.12 was released which integrates the changes to the Spring framework and spring-beans. Note: The latest Spring Boot release, 2.6.5, does NOT have these fixes in place. The Spring Boot team is working on release 2.6.6 which will include these updates as well. We’ll keep you posted when that becomes available.

Here’s a list of remediation steps you can take in order of preference:

  • If you use Spring Framework directly, upgrade to version 5.2.20
  • If you use Spring Boot, use version 2.15.12. Note: This may represent a downgrade if you are already on 2.6.x as that version has not yet been updated to integrate these fixes
  • If you can’t upgrade your version of Spring at this time, use a version 8 JRE and/or Tomcat container to mitigate the issue

It’s worth noting that there will likely be additional updates to Spring as more (and potentially different) vulnerabilities are discovered. This is often the trajectory when a high degree of focus is put on a high severity issue like this (Log4Shell, anyone?).

Snyk’s tools have already been updated to notify you if you’re project is vulnerable!

Head on over to Snyk to sign up for a free account. From there (or on the command line) you can test your project to see if it’s vulnerable to Spring4Shell.

We expect to update this post and to produce a PoC code repository to demonstrate the RCE in version 9 and greater of the JRE and Tomcat. Tune in here for updates.

Source :
https://snyk.io/blog/is-there-such-a-thing-as-spring4shell/

Exit mobile version