CVE-2021-21290: Netty Information Disclosure Vulnerability

CVE-2021-21290 Overview

CVE-2021-21290 is an information disclosure vulnerability in Netty, an open-source asynchronous event-driven network application framework widely used for developing high-performance protocol servers and clients. The vulnerability exists in Netty's multipart decoders on Unix-like systems, where insecure handling of temporary files can lead to local information disclosure when temporary storage of uploads on disk is enabled.

Critical Impact
Local attackers on Unix-like systems can read sensitive information from temporary files created by Netty's multipart decoders due to overly permissive default file permissions, potentially exposing uploaded data to unauthorized users.

Affected Products

Netty versions prior to 4.1.59.Final
Debian Linux 9.0 and 10.0
Quarkus (versions using vulnerable Netty)
Oracle Banking Corporate Lending Process Management (14.2.0, 14.3.0, 14.5.0)
Oracle Banking Credit Facilities Process Management (14.2.0, 14.3.0, 14.5.0)
Oracle Banking Trade Finance Process Management (14.2.0, 14.3.0, 14.5.0)
Oracle Communications BRM - Elastic Charging Engine 12.0.0.3
Oracle Communications Design Studio 7.4.2
Oracle Communications Messaging Server 8.1
Oracle NoSQL Database
NetApp Active IQ Unified Manager (Linux and Windows)
NetApp Cloud Secure Agent
NetApp SnapCenter

Discovery Timeline

2021-02-08 - CVE-2021-21290 published to NVD
2024-11-21 - Last updated in NVD database

Technical Details for CVE-2021-21290

Vulnerability Analysis

This vulnerability stems from insecure file permission handling in Netty's AbstractDiskHttpData class. On Unix-like systems, the system temporary directory (/tmp) is shared between all users. When Netty's multipart decoders write uploaded data to temporary files using Java's File.createTempFile() method, these files are created with default permissions of -rw-r--r-- (644), making them readable by all local users on the system.

The vulnerability specifically impacts applications that use Netty's HTTP multipart handling with disk-based temporary storage enabled. When sensitive data such as authentication tokens, user uploads, or other confidential information is written to these temporary files, any local user can read the contents before the files are cleaned up. This represents a significant confidentiality breach in multi-user environments.

It's important to note that modern macOS operating systems are not affected by this vulnerability due to different default temporary directory permissions.

Root Cause

The root cause lies in the use of the standard Java File.createTempFile() API, which on Unix-like systems creates files with world-readable permissions by default. The AbstractDiskHttpData class in Netty's HTTP codec did not explicitly set restrictive file permissions when creating temporary files for storing multipart HTTP data. Similarly, the NativeLibraryLoader class used the same insecure pattern when extracting native libraries to temporary files.

Attack Vector

This is a local attack vector requiring the attacker to have existing access to the same Unix-like system where the vulnerable Netty application is running. The attack proceeds as follows:

An attacker with local system access monitors the system temporary directory (/tmp or configured java.io.tmpdir)
When a legitimate user uploads data through a Netty-based application with disk storage enabled, the data is written to a world-readable temporary file
The attacker reads the sensitive uploaded data from the temporary file before it is deleted
No special privileges are required beyond basic local user access

java

// Security patch showing migration from File.createTempFile to secure alternative
// Source: https://github.com/netty/netty/commit/c735357bf29d07856ad171c6611a2e1a0e0000ec

// Before (vulnerable):
// tmpFile = File.createTempFile(prefix, suffix, WORKDIR);

// After (fixed in NativeLibraryLoader.java):
tmpFile = PlatformDependent.createTempFile(prefix, suffix, WORKDIR);

The fix uses Files.createTempFile() which creates files with permissions restricted to the owner only, wrapped through PlatformDependent.createTempFile() for consistent secure behavior across platforms.

Detection Methods for CVE-2021-21290

Indicators of Compromise

Unusual file access patterns in the system temporary directory (/tmp or custom java.io.tmpdir)
Multiple users reading temporary files with patterns matching Netty's naming conventions
Unexpected processes monitoring or scanning the temporary directory
Evidence of file enumeration activities targeting Java application temporary files

Detection Strategies

Monitor file access events in system temporary directories for unauthorized read operations by non-owning users
Implement file integrity monitoring on temporary directories to detect suspicious access patterns
Review application logs for multipart upload activities and correlate with file system access logs
Use endpoint detection tools to identify processes performing directory enumeration on /tmp
Audit Java applications for use of vulnerable Netty versions in dependency trees

Monitoring Recommendations

Enable file access auditing on Unix-like systems for the /tmp directory and any custom temporary directories
Configure SentinelOne behavioral AI to detect unusual file access patterns in shared directories
Implement alerting for any non-owner read access to temporary files created by Java applications
Monitor for rapid sequential file reads in temporary directories that may indicate automated data exfiltration

How to Mitigate CVE-2021-21290

Immediate Actions Required

Upgrade Netty to version 4.1.59.Final or later immediately
Audit all applications using Netty as a dependency and update accordingly
Review temporary directory permissions on affected systems
Consider implementing additional access controls on system temporary directories
For Java applications that cannot be immediately updated, configure a dedicated secure temporary directory

Patch Information

The vulnerability has been fixed in Netty version 4.1.59.Final. The fix replaces the use of File.createTempFile() with Files.createTempFile() through the PlatformDependent.createTempFile() wrapper, which creates files with owner-only permissions on Unix-like systems. The patch is available via the GitHub commit and the GitHub Security Advisory.

Oracle has addressed this vulnerability in multiple Critical Patch Updates including April 2021, October 2021, and April 2022 for affected Oracle products.

Workarounds

Specify a custom temporary directory with restricted permissions using the -Djava.io.tmpdir JVM argument when starting the application
Use DefaultHttpDataFactory.setBaseDir(...) to configure Netty to use a directory that is only readable by the current user
Implement directory-level access controls using file system permissions or ACLs to restrict the temporary directory
On systemd-based systems, use PrivateTmp=true in service units to provide isolated temporary directories

bash

# Configuration example - Set secure temporary directory with restricted permissions
# Create a dedicated temporary directory for the application
mkdir -p /opt/app/secure-tmp
chown appuser:appgroup /opt/app/secure-tmp
chmod 700 /opt/app/secure-tmp

# Start Java application with custom tmpdir
java -Djava.io.tmpdir=/opt/app/secure-tmp -jar mynettyapp.jar