Overview
Spring Boot provides a ready to use preconfiguration of the Spring platform to allow users to quickly develop Java applications. By leveraging Spring Framework, Spring Boot simplifies the development of web application while offering a variety of tools to manage application configuration, data access, and security.
A signature forgery vulnerability path traversal vulnerability (CVE-2024-38807) has been identified in Spring Boot. This vulnerability could allow hacker to make content that appears to be signed as one user actually signed by another. This affects applications that use spring-boot-loader or spring-boot-loader-classic and use custom code to do signature verification of nested jars.
This issue affects Spring Boot versions >=2.7.0 through <=2.7.21, >=3.0.0 through <=3.0.16, >=3.1.0 through <=3.1.12, >=3.2.0 through <=3.2.8, and >=3.3.0 through<=3.3.2.
Details
Module Info
- Product: Spring Boot
- Affected packages & versions: some text
- spring-boot-loader – versions >=2.7.0 through <=2.7.21
- spring-boot-loader-classic – versions: >=3.0.0 through <=3.0.16, >=3.1.0 through <=3.1.12, >=3.2.0 through <=3.2.8, and >=3.3.0 through<=3.3.2
- GitHub repository: https://github.com/spring-projects/spring-boot
- Package manager: Maven
Vulnerability Info
This Medium-severity vulnerability is found in the spring-boot-loader and spring-boot-loader-classic packages of Spring Boot in versions highlighted above.
The vulnerability exists in Spring Boot-powered applications that leverage custom code to validate signed jars that are nested in other jars can incorrectly attribute the signature of an earlier-loaded Jar.
The vulnerability is caused by a gap in how nested Jars and certificates are loaded and processed at runtime. The result is that applications that depend on cryptographic signatures before executing dynamic code can validate an unsigned, mismatched or otherwise invalid Jar as signed.
Steps To Reproduce
Reproducing the loading of invalid signatures missing or invalid signatures can be done with the following steps:
- Create or choose a Jar and sign it using the jarsign utility.
- Add a separately compiled class file (i.e. Foo.class) to the Jar (i.e. invalid.jar).
- Validate the jar is indeed invalid: jarsigner -verify invalid.jar
- Nest the invalid jar inside another Jar (i.e. parent.jar)
- Configure your application to ensure parent.jar is loaded, as well as invalid.jar.
- Note that both jars are loaded with no warning.
Note that applications performing custom signature verification can also be affected. The steps to reproduce this vulnerability are highly application dependent, so our team will update our steps to reproduce the problem as appropriate. If you feel your projects might be affected in this manner, contact the HeroDevs team to discuss your specific project circumstances.
Mitigation
- Spring Boot 3.2 and 3.3 users should update to the latest community supported source version where this issue is addressed (at least 3.29 and 3.3.3 respectively).
- Other versions of Spring Boot including 2.7 are no longer community-supported. The community support version will not receive any updates to address this issue. For more information, see here.
- Spring Boot users on 2.6.x and below are not directly affected by this vulnerability as signature verification was introduced in 2.7.0, but it is still possible that Jars with invalid signatures will load without error in these versions. As such, we recommend all projects be updated to a supported version of Spring Boot.
- Ensure all jars are appropriately signed and valid to limit risk and prevent runtime errors.
For users looking for time to migrate, they can leverage a commercial support partner like HeroDevs for post-EOL security support.
Credit
References
