A brace of critical new vulnerabilities in the Spring framework have sent security professionals scrambling.
Here's what CIOs and others should know about both the vulnerabilities and Spring.
Spring is the most popular framework for Java. Big users include Netflix, many others.
It provides infrastructure support for those developing Java applications (which is a LOT of people and organisations). It is "owned" by the software multinational VMware which runs it as an open source community.
Two critical remotely exploitable Spring framework vulnerabilities were reported this week.
Spring framework vulnerabilities: CVE-2022-22965 vs CVE-2022-22963
News of one new remote code execution (RCE) vulnerability that affects the Spring Framework emerged on March 30 via a Chinese Twitter account showing screenshots of the 0day being exploited. These were then promptly deleted. Security researchers rapidly dubbed the vulnerability "Springshell" or "Spring4Shell".
Spring has now acknowledged the vulnerability, allocated CVE-2022-22965, and issued a patch.
Exploits have circulated.
As Sonatype field CTO Ilkka Turunen told The Stack on March 30: "The chances are that anyone who writes or runs software built with Java will have Spring as a part of their software supply chain.
"There are vulnerabilities regularly for it, but just like Log4J a new low-skilled attack combined with high popularity makes this extremely likely to be exploited. This is why we advice immediate action and awareness.
Follow The Stack on LinkedIn for more
The vulnerability appears to be due to a bypass for an earlier bug, allocated CVE-2010-16722.
Spring Framework versions 5.3.18 and 5.2.20 address the vulnerability and are now available.
The vulnerability impacts Spring MVC and Spring WebFlux applications running on JDK 9+.
The specific exploit requires the application to run on Tomcat as a WAR deployment, Spring said on March 31: "If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit. However, the nature of the vulnerability is more general, and there may be other ways to exploit it."
As Veracode's research team noted: "The cause is due to unforeseen access to Tomcat’s ClassLoader as a result of the new Module feature added in Java 9. An existing mitigation only blocked access to the classLoader property of Class objects, but the new Module object also has a classLoader property and was therefore accessible through Spring’s property bindings when a Java object is bound to a request parameter.
"Access to the classLoader property is then combined with a well-known method for performing an arbitrary file write using the Tomcat AccessLogValve class, potentially allowing an attacker to write a malicious JSP file accessible via the application server" they added in a blog published March 31.
Spring's Rossen Stoyanchev said: "The issue was first reported to VMware late on Tuesday evening, close to Midnight, GMT time by codeplutos, meizjm3i of AntGroup FG [an affiliate of China's Alibaba Group]. On Wednesday we worked through investigation, analysis, identifying a fix, testing, while aiming for emergency releases on Thursday... in the mean time, also on Wednesday, details were leaked in full detail online..."
On March 29, another RCE vulnerability for Spring Cloud Function was released. This is a separate, also critical bug, allocated CVE-2022-22963. VMware notes: "In Spring Cloud Function versions 3.1.6, 3.2.2 and older unsupported versions, when using routing functionality it is possible for a user to provide a specially crafted SpEL as a routing-expression that may result in remote code execution and access to local resources."
Patches are available for both new Spring framework vulnerabilities.
Sonatype, which has been tracking SpringShell closely, noted: "The claims [of the 0day] were anecdotally confirmed Wednesday at 15:00 GMT when a Proof-of-Concept (PoC) exploit surfaced on an original GitHub repository, shared with a Sonatype researcher by a source. The PoC leverages a previously unknown method to achieve RCE. Present in the GitHub repo were also PDF with detailed exploit instructions."
Millions of companies will likely be forced -- if they are paying attention -- to conduct an audit of their applications in coming days and weeks to see if they are exposed. Weaponisation may follow fast.
Per Veracode, mitigation measures include:
- Upgrade to the latest Spring Framework versions by changing your build files.
- If you can’t upgrade, use one of the following DataBinder allow/disallow configurations ordered by level of effectiveness:
- Use an allowlist containing only properties that are expected from the requests
- Extend RequestMappingHandlerAdapter
- If you can’t do a or b, apply a disallow list using @ControllerAdvice for a central configuration
- If you can’t do a, b, or c, configure a disallow list in every single Controller
If using disallow list, it should include the below values:
"class.*", "Class.*", "*.class.*", "*.Class.*"
But is SpringShell really being weaponised?
UPDATED April 4: Security teams at Radware and Akamai say that they are seeing thousands of probes daily for exposed web applications. But applications specifically exposed in the configurations required to launch an attack seem to remain few and far between at present -- critics say the incident is over-hyped.
Following in the wake of the Log4J security issue the incident, to David A. Wheeler, Director of Open Source Supply Chain Security, Linux Foundation, is a reminder of how important it is to have a software bill of materials (SBOM) to hand to check which version of Spring Framework you are using in various applications.
“For those who don’t yet have SBOMs in place, this incident should act as yet another reminder of their importance. SBOMs act as a list of ingredients and enable organizations to understand which third-party components are in their applications, so that they can quickly identify any risks and reduce the potential impact of any vulnerabilities in their supply chains. Organizations must set their houses in order or risk leaving their systems exposed.
"An obvious approach [to generating a SBOM] is to adopt the International Organization for Standardization (ISO) standard, the Software Package Data Exchange (SPDX), an open standard for communicating software bill of materials information, which enables companies to respond more rapidly following vulnerabilities such as the one impacting Spring Framework. Organizations’ application development processes should also have a variety of tools in their continuous integration (CI) pipeline that look for vulnerabilities, including known vulnerabilities in dependencies. Finally, organizations need to ensure that their developers are trained in how to develop secure software, including how to evaluate reusable components and prepare for vulnerability announcements.”
