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)’