Overview
Spring is a Java framework typically used for enterprise and web applications, though it can be used for desktop applications, as well. It is composed of many modules and not all modules are used by every deployment.
This vulnerability (CVE-2024-38808) is in the spring-expression library, which is responsible for evaluating Spring Expression Language (SpEL) expressions. In flawed versions of the library, it is possible for a user to provide a specially crafted, user-supplied SpEL expression that may cause a denial of service (DoS) condition.
The Open Web Application Security Project (OWASP) explains that denial of service (DoS) attacks aim to make a service “unavailable for the purpose it was designed.” In this case, the vulnerability allows susceptible SpEL expressions to use most system resources and deny other users access to the system.
This issue affects multiple versions of spring-expression from Spring Framework.
Details
Module Info
- Product: Spring Framework
- Affected packages: spring-expression
- Affected version: <5.3.39
- GitHub repository: https://github.com/spring-projects/spring-framework/tree/main/spring-expression
- Published packages: https://central.sonatype.com/artifact/org.springframework/spring-expression
- Package manager: Maven
- Fixed in: NES for Spring Framework v4.3.32 and v5.3.44
Vulnerability Info
This Medium-severity vulnerability is found in the spring-expression.jar module of the Spring Framework. When user-supplied Spring Expression Language (SpEL) expressions are evaluated, it is possible to exhaust system resources.
Consider the following mitigation options if upgrading to a corrected version of the library (5.3.39 or later, including version 6) is not immediately available:
- Restrict SpEL Permissions and Operators: Use StandardEvaluationContext to control access tightly if you must evaluate complex expressions. Restrict specific classes, methods, and properties within SpEL by setting up custom resolvers to whitelist only safe methods and operators.
- Implement Rate Limiting and Throttling: Even with SimpleEvaluationContext, adding rate limiting or throttling can help prevent resource exhaustion from repeated requests or complex expression evaluations, adding another layer of defense.
- Sanitize Input: For applications that need to process some dynamic expressions, adding pre-validation steps to sanitize input can prevent malicious or unexpected constructs from reaching the evaluation stage.
- Monitor Resource Usage: For applications particularly vulnerable to DoS, monitoring and alerting on CPU and memory usage can help detect unusual spikes, allowing you to respond to potential attacks swiftly.
Steps To Reproduce
To reproduce this vulnerability in a controlled environment, you would need a Spring application running an affected version and an available end point.
1. Set up a vulnerable Spring application:
- Create a simple Spring Boot application using a vulnerable Spring Framework version, such as 5.3.38
2. Add additional files to fill out the project. Launch the app.
3. Craft a malicious request that causes extensive computation or memory usage similar to the one below:
String maliciousExpression = "#{'malicious'.concat(''.concat( /* numerous concatenations to cause excessive computation */))}";
4. Send the request to an end-point in the application. Use a tool like curl or Postman and replace “your-spel-endpoint” below:
curl -X POST -H "Content-Type: application/json" -d '{"expression":"#{'malicious'.concat(''.concat( /* many concatenations */))}"}' http://localhost:8080/your-spel-endpoint
5. Observe the impact:
- Monitor the server's CPU, memory, and disk usage with monitoring tools. The denial-of-service (DoS) impact should be noticeable as the server executes the expression.
- Server logs may also show system degradation.
- A partial workaround is to avoid using user-supplied expressions or, if that is unavoidable, to ensure that SimpleEvaluationContext is in read-only mode to limit (but not eliminate) the possibility of resource exhaustion.
Credits
- This issue was identified and responsibly reported by popko.
Mitigation
Spring Framework 4 and 5 are no longer community-supported. The community support version will not receive any updates to address this issue. For more information, see here.Users of the affected components should apply one of the following mitigations:
- Upgrade to a corrected version
- Leverage a commercial support partner like HeroDevs for post-EOL security support.