CVE-2020-15250: JUnit4 Information Disclosure Vulnerability

CVE-2020-15250 Overview

CVE-2020-15250 is a local information disclosure vulnerability in JUnit4's TemporaryFolder test rule affecting versions 4.7 through 4.13.0. On Unix-like systems, the system's temporary directory (/tmp) is shared between all users. When JUnit tests use TemporaryFolder to create files and directories, these are created with default permissions that allow other users on the same system to read the contents. This vulnerability is particularly concerning in multi-tenant environments such as shared CI/CD systems, development servers, or containerized environments where test processes may write sensitive information to temporary storage.

Critical Impact

Sensitive information such as API keys, passwords, database credentials, or test data written by JUnit tests can be exposed to other users on shared Unix-like systems, potentially leading to credential theft or unauthorized access to downstream systems.

Affected Products

• JUnit4 versions 4.7 through 4.13.0
• Debian Linux 9.0
• Apache Pluto (various versions)
• Oracle Communications Cloud Native Core Policy 1.14.0

Discovery Timeline

• 2020-10-12 - CVE-2020-15250 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2020-15250

Vulnerability Analysis

The vulnerability exists in the TemporaryFolder class, a JUnit test rule designed to create temporary files and directories that are automatically cleaned up after test execution. The root issue is that the implementation uses standard Java file creation methods that inherit the system's default umask settings, typically resulting in world-readable permissions (e.g., 644 for files, 755 for directories).

On multi-user Unix systems, this means any user with shell access can enumerate and read files created in /tmp by JUnit test processes. While the vulnerability does not allow modification or deletion of these files by unauthorized users, the confidentiality impact is significant when tests write sensitive data such as configuration files containing credentials, API tokens, or personally identifiable information.

The fix requires Java 1.7 or higher to leverage the java.nio.file APIs which support specifying POSIX file permissions at creation time. For users on Java 1.6 or earlier, no patch is available through JUnit itself.

Root Cause

The root cause is CWE-732 (Incorrect Permission Assignment for Critical Resource) combined with CWE-200 (Exposure of Sensitive Information). The TemporaryFolder implementation did not explicitly set restrictive file permissions when creating temporary files and directories, relying instead on system defaults which are typically permissive on Unix-like systems.

Attack Vector

This vulnerability requires local access to the target system. An attacker must be able to read the shared temporary directory (typically /tmp) on a Unix-like system where vulnerable JUnit tests are executing. The attack requires no privileges beyond basic shell access and user interaction is required only in the sense that the vulnerable tests must be running. The attack flow is:

1. Attacker gains shell access to a shared system (CI/CD server, development machine, etc.)
2. Attacker monitors the /tmp directory for newly created files from JUnit test processes
3. Attacker reads files containing sensitive test data before cleanup occurs
4. Sensitive credentials or data are extracted for further attacks

// Security patch from JUnit4 - Import additions for POSIX permission handling
// Source: https://github.com/junit-team/junit4/commit/610155b8c22138329f0723eec22521627dbc52ae
 
import java.io.File;
import java.io.IOException;
+import java.lang.reflect.Array;
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
 
import org.junit.Rule;

Source: JUnit4 Security Patch Commit

The patch introduces reflection-based invocation of Java NIO APIs to set restrictive POSIX permissions on created files and directories, ensuring only the owning user can read the contents.

Detection Methods for CVE-2020-15250

Indicators of Compromise

• World-readable files appearing in /tmp or system temporary directories with patterns matching JUnit temporary folder naming conventions
• Process monitoring showing JUnit test executions writing to shared temporary directories with insecure permissions
• Audit logs indicating non-authorized users accessing files in temporary directories created by test frameworks

Detection Strategies

• Implement file permission auditing on shared systems to detect world-readable files in /tmp directories
• Use dependency scanning tools to identify JUnit4 versions between 4.7 and 4.13.0 in project dependencies
• Monitor CI/CD pipeline configurations for tests that may write sensitive data to temporary storage

Monitoring Recommendations

• Enable audit logging for file access events in shared temporary directories on multi-user systems
• Implement automated dependency vulnerability scanning in build pipelines to flag vulnerable JUnit versions
• Review test code for patterns that write credentials, API keys, or sensitive configuration to TemporaryFolder resources

How to Mitigate CVE-2020-15250

Immediate Actions Required

• Upgrade JUnit4 to version 4.13.1 or later for Java 1.7+ environments
• Audit existing test code for sensitive data written to TemporaryFolder resources and remediate as needed
• For Java 1.6 environments, implement the java.io.tmpdir workaround immediately
• Review CI/CD and shared development environments for potential exposure

Patch Information

The vulnerability is fixed in JUnit4 version 4.13.1 for users running Java 1.7 or higher. The fix is documented in the JUnit 4.13.1 Release Notes and the security issue is tracked in GitHub Security Advisory GHSA-269g-pwp5-87pp. Oracle has also addressed this in downstream products via their April 2022 Security Alert.

Workarounds

• For Java 1.6 users: Set the java.io.tmpdir system property to a directory exclusively owned by the executing user
• Restrict permissions on the system temporary directory at the OS level where possible
• Avoid writing sensitive data in JUnit tests; use mocked credentials or secure credential injection instead
• Consider running tests in isolated containers or dedicated VMs to minimize exposure on shared systems

# Workaround: Set a user-owned temporary directory for JUnit tests
# Create a secure temp directory with restrictive permissions
mkdir -p /home/$USER/secure_tmp
chmod 700 /home/$USER/secure_tmp

# Run tests with custom temp directory
java -Djava.io.tmpdir=/home/$USER/secure_tmp -jar junit-tests.jar