Spring Framework RCE Vulnerability – Current BigFix Actions

The BigFix team is actively investigating the Spring Framework RCE (Remote Code Execution) vulnerability which was announced 31-March-2022. BigFix is currently focused on detecting the deployment that can exploit the vulnerability to assist with your organization’s vulnerability assessment activities. As more information is known around vulnerability remediations, we’ll add that as a secondary focus.

As always, our intent is to provide content and guidelines to assist our customers with such announcements in as timely a manner as possible. We will continue to post updates with our recommended actions and solutions in this space.

At this time, no BigFix product is believed to be impacted by these Spring vulnerabilities.

RCE Announcement Details

There has been some confusion in the Cyber Security community this week as at least Spring vulnerabilities are being discussed as well as an unrelated code commit to the Spring codebase. HCL BigFix is investigating methods to determine the versions of Spring Framework that are present and to help customers determine their vulnerability status. We are currently tracking CVE-2022-22965, CVE-2022-22963, and CVE-2022-22950 as described at the following links:

Vendor Announcement Details

From Spring’s post, these are the currently known details. Follow the link to stay abreast of additional information as provided by the vendor.

Overview

[…] announce an RCE vulnerability in the Spring Framework that was leaked out ahead of CVE publication. The issue was first reported to VMware late on Tuesday evening, close to Midnight, GMT time by codeplutos, meizjm3i of AntGroup FG. 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, which is why we are providing this update ahead of the releases and the CVE report.

Vulnerability

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. 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.

Am I Impacted?

These are the requirements for the specific scenario from the report:

  • JDK 9 or higher

  • Apache Tomcat as the Servlet container

  • Packaged as a traditional WAR (in contrast to a Spring Boot executable jar)

  • spring-webmvc or spring-webflux dependency

  • Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions

However, the nature of the vulnerability is more general, and there may be other ways to exploit it that have not been reported yet.

Note: These Tasks and Analysis are detection-only. We have not identified any actionable workarounds and do not expect any workarounds to be forthcoming. Application vendors and developers will need to update their Spring library usage to remove the vulnerability.

Note: Based on customer demand, we do not expect to provide out-of-box content to perform this scan. The Community tasks and analysis posted to BigFix.me will be updated as necessary if issues are reported, but do not expect to provide officially-supported content for Spring detection.

2022-04-01: Initial posting
2022-04-05: Add notes related to Remediation and Official Content

4 Likes

I have uploaded a Scanning Tasks and Analysis to attempt a filesystem scan searching for Spring libraries, for Windows and Linux systems.

This is Community Content. When you use these solutions, it is incumbent on your organization to test any solutions provided across the broadest available system base including various OS, storage solutions, and application inventory.

Please see the Community Solution Testing Statement at Log4j Vulnerability Identification and 3rd Party Remediation Solution Testing Statement

These Scanning tasks search local fixed disks, looking for both .JAR files with the Spring naming conventions, as well as all .WAR files on the machine. When .WAR files are found, the ‘unzip’ utility is used to extract a list of filenames embedded in the .WAR and any matching Spring files are returned.

Please test these methods with care, and at your own risk. I have only been able to test on a small set of systems (Windows and CentOS 8, at this time). If you would like to try the Linux scan on Mac or other Linux distributions, you may try updating the Relevance as necessary. I’d recommend downloading copies of the Spring distribution from JFrog to test that you obtain valid scan results; any of the distribution .ZIP files may be renamed to .WAR to test embedded WAR scanning.

Known limitations -

  • The Scans run with no CPU or Disk I/O throttling. When scanning systems with shared storage (Virtual Machines, SAN connections, etc.) take care to stagger scan times to prevent overloading Storage or Processor systems.
  • The scans attempt to exclude network paths, but I have not been able to validate all types of network storage.
  • The scans only check one-level-deep on compressed .WAR files. If a .WAR archive itself contains other .WAR archives, the deeper levels of container are not scanned.
  • The scans may not detect all use-cases of Spring libraries, especially where an application may reference a Spring library via a URL, container, serverless cloud function, etc. where the affected .JAR files may not be present on the endpoint. This scan may be only a starting point to understanding your exposures.
  • The Analysis results do not distinguish between “good” or “bad” versions of Spring. At this time, all Spring Framework versions below 5.3.18 or 5.2.20 are considered vulnerable, as well as all Spring Boot below 2.6.6 or 2.5.12.
  • Detections for Spring Boot may be incomplete; I am still looking for detection methods on Spring Boot, any help in this area is welcome

With those limitations out of the way, here are links (which I will update as new versions are published)

Windows Scan:
https://bigfix.me/fixlet/details/26932

Linux Scan:
https://bigfix.me/fixlet/details/26921

Analysis Results:
https://bigfix.me/analysis/details/2998672

Note: These Tasks and Analysis are detection-only. We have not identified any actionable workarounds and do not expect any workarounds to be forthcoming. Application vendors and developers will need to update their Spring library usage to remove the vulnerability.

Note: Based on customer demand, we do not expect to provide out-of-box content to perform this scan. The Community tasks and analysis posted to BigFix.me will be updated as necessary if issues are reported, but do not expect to provide officially-supported content for Spring detection.

2022-04-01: Initial posting
2022-04-05: Add notes related to Remediation and Official Content
2022-05-11: Updated Windows scan to correct error on folders with spaces.
2022-05-11: Updated Windows scan to correct error on folders with parentheses ‘Program Files (x86)’

3 Likes

Thanks for this!
The Windows Scan fixlet and the Analysis Results fixlet appear to be identical. Can you confirm?

1 Like

Thank you for pointing this out, I seem to have uploaded the file twice. New link to the Analysis is https://bigfix.me/analysis/details/2998672.

2 Likes

Adding a disclaimer to the thread, I have edited the initial post and the post containing the BigFix.me links –

Note: These Tasks and Analysis are detection-only. We have not identified any actionable workarounds and do not expect any workarounds to be forthcoming. Application vendors and developers will need to update their Spring library usage to remove the vulnerability.
Note: Based on customer demand, we do not expect to provide out-of-box content to perform this scan. The Community tasks and analysis posted to BigFix.me will be updated as necessary if issues are reported, but do not expect to provide officially-supported content for Spring detection.

2022-04-05: Add notes related to Remediation and Official Content

1 Like

Thanks again for the hard work @JasonWalker just a quick question, some of my results are coming back with a Completed Exit Code of 255 while others are 0, should I be curious of the 255 results?

An exit code 255 is likely indicating an error in the script - I recall this being a common return code when an error occurs.

What OS is this occuring on? You’ll likely need to step through the script components and see where it’s failing.

I honestly should have done my homework lol, this prompted me to dig further and despite the Exit Code of 255 the results are being generated and being pulled into the results analyses. Sorry to run up a red flag.

I’m still not comfortable with the 255 though…is this occurring on Linux or Windows, and which versions/distributions?

So far I scanned 436 servers (all Windows) 54 of them returned the code 255 and are a variety of versions Win2008, Win2008R2, Win2012R2, Win2016, and Win2019.

I sent a private message to try and troubleshoot on your environment

Corrected a problem with the Windows scan dealing with spaces in folder names, link updated in the post above.

And…a second update to with the Windows scan dealing with parentheses in folder names, link updated in the post above.