Overview
Spring Boot helps developers to create Spring-based applications with minimal configuration. Production-grade features are provided out-of-the box. Common Spring features can be enabled by adding “starter” modules to a project, with sensible defaults that can easily be overridden.
A temporary directory hijacking vulnerability (CVE-2022-27772) has been identified in Spring Boot, which could allow a directory that a Spring Boot application intends to create as a temporary workspace for an embedded web server to be hijacked by someone who is closely watching the file system of the machine that the application is running on.
This issue affects Spring Boot versions less than 2.2.11.
Details
Module Info
- Product: Spring Boot
- Affected packages: spring-boot
- Affected versions: <2.2.11
- GitHub repository: https://github.com/spring-projects/spring-boot
- Package manager: Maven
- Fixed in: NES for Spring Boot v1.5.24
Vulnerability Info
Applications using Spring Boot can embed a web container such as Tomcat, Jetty, or Undertow in the application. When starting an embedded web container, Spring Boot creates a temporary working directory on the local file system of the machine running the application for use by the web container. The temporary directory might contain configuration files and Java class files.
The temporary directory is created with a series of Java API calls:
protected final File createTempDir(String prefix) {
try {
File tempDir = File.createTempFile(prefix + ".", "." + getPort());
tempDir.delete();
tempDir.mkdir();
tempDir.deleteOnExit();
return tempDir;
}
catch (IOException ex) {
throw new EmbeddedServletContainerException(
"Unable to create tempDir. java.io.tmpdir is set to " +
System.getProperty("java.io.tmpdir"), ex);
}
}
An attacker can watch the file system that the application is running on for the creation and deletion of the file with the name passed to File.createTempFile(). The location of the created file is determined by the system environment variable java.io.tmpdir, which defaults to /tmp on Unix-like systems and is shared by all users of the system.
If the attacker can create a directory with the same name between the time that tempDir.delete()completes and tempDir.mkdir() starts, then the tempDir.mkdir() call will fail silently and the attacker will have full control over the created directory for the life of the application execution. This would allow the attacker to modify any configuration files, Java class files, or other types of files used by the web container.
Steps to Reproduce
Reproduction requires an application to be written and executed on the same machine as the Spring Boot application (or on a machine that has access to the system temporary directory of the Spring Boot application). The attacking application would need to be running before the Spring Boot application starts. When the Spring Boot application starts, the attacking application would watch for files matching certain patterns (depending on the embedded web container implementation) to be created and then deleted, and detect the deletion in time to create a directory with the same name.
Credits
- Jonathan Leitschuh
Mitigation
Spring Boot 1.5 and 2.2 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 affected applications to supported versions of Spring Boot.
- Set the system environment variable java.io.tmpdir to a directory that is owned exclusively by the user executing the Spring Boot application instead of the machine default temporary directory.
- Leverage a commercial support partner like HeroDevs for post-EOL security support.
