CVE-2022-24823: Netty HTTP Codec Information Disclosure

CVE-2022-24823 Overview

CVE-2022-24823 is an Information Disclosure vulnerability in Netty, the popular open-source asynchronous event-driven network application framework. The vulnerability exists in the io.netty:netty-codec-http package and represents an insufficient fix for the earlier CVE-2021-21290. When Netty's multipart decoders are configured with temporary disk storage for uploads, local information disclosure can occur through the system temporary directory due to improper file permission handling.

Critical Impact

Local attackers on multi-user systems can potentially access sensitive data from temporary files created by Netty applications, exposing uploaded content and other multipart data to unauthorized users sharing the same temporary directory.

Affected Products

• Netty versions prior to 4.1.77.Final
• Oracle Financial Services Crime and Compliance Management Studio versions 8.0.8.2.0 and 8.0.8.3.0
• NetApp Active IQ Unified Manager (Linux and Windows)
• NetApp OnCommand Workflow Automation
• NetApp SnapCenter

Discovery Timeline

• 2022-05-06 - CVE-2022-24823 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2022-24823

Vulnerability Analysis

This vulnerability stems from insufficient file permission enforcement when Netty creates temporary files for multipart data handling. The io.netty:netty-codec-http package's multipart decoders can store uploaded data temporarily on disk. When this feature is enabled, the temporary files are created with overly permissive default permissions inherited from the system's temporary directory settings.

The vulnerability specifically impacts applications running on Java 6 and lower, as well as code running on Unix-like systems and very old versions of Mac OSX and Windows where the system temporary directory (/tmp on Unix-like systems) is shared between all users on the system. An attacker with local access to the same machine could read temporary files created by other users' Netty applications.

Root Cause

The root cause lies in the improper handling of file permissions when creating temporary files through the File.createTempFile() method. The original fix for CVE-2021-21290 attempted to restrict file permissions after creation, but the permission-setting operations were not properly validated for success. If the setReadable() calls failed silently, the files would remain world-readable, defeating the security controls.

Attack Vector

The attack requires local access to a multi-user system where the vulnerable Netty application is running. The attacker must:

1. Have a valid user account on the same system as the target application
2. Access the shared system temporary directory (typically /tmp on Unix systems)
3. Read temporary files created by the Netty multipart decoder before they are cleaned up
4. Extract sensitive data from uploaded multipart content

             }
             return Files.createTempFile(directory.toPath(), prefix, suffix).toFile();
         }
+        final File file;
         if (directory == null) {
-            return File.createTempFile(prefix, suffix);
+            file = File.createTempFile(prefix, suffix);
+        } else {
+            file = File.createTempFile(prefix, suffix, directory);
         }
-        File file = File.createTempFile(prefix, suffix, directory);
+
         // Try to adjust the perms, if this fails there is not much else we can do...
-        file.setReadable(false, false);
-        file.setReadable(true, true);
+        if (!file.setReadable(false, false)) {
+            throw new IOException("Failed to set permissions on temporary file " + file);
+        }
+        if (!file.setReadable(true, true)) {
+            throw new IOException("Failed to set permissions on temporary file " + file);
+        }
         return file;
     }

Source: GitHub Commit Update

Detection Methods for CVE-2022-24823

Indicators of Compromise

• Presence of world-readable temporary files in /tmp or system temp directory with Netty-related naming patterns
• Unusual file access patterns in the temporary directory from non-application users
• Log entries indicating failed permission operations on temporary files
• Evidence of local users accessing or enumerating the temporary directory

Detection Strategies

• Monitor file creation events in system temporary directories for files associated with Netty multipart handling
• Implement file permission auditing on temporary directories to detect world-readable files created by Java applications
• Review application logs for IOException messages related to file permission failures
• Use endpoint detection to identify processes accessing temporary files outside their normal scope

Monitoring Recommendations

• Configure file integrity monitoring on the system temporary directory
• Enable audit logging for file access events in /tmp or configured temp directories
• Monitor for lateral movement attempts that target temporary file contents
• Alert on applications running with Java 6 or earlier that use Netty's HTTP codec

How to Mitigate CVE-2022-24823

Immediate Actions Required

• Upgrade Netty to version 4.1.77.Final or later immediately
• Audit all applications using io.netty:netty-codec-http for multipart decoder usage with disk storage enabled
• Review and restrict permissions on system temporary directories where possible
• Consider disabling disk-based temporary storage for multipart data if not strictly required

Patch Information

The vulnerability is fixed in Netty version 4.1.77.Final. The patch ensures that permission-setting operations on temporary files are validated and will throw an IOException if they fail, preventing the creation of insecure temporary files. Organizations should update through their standard dependency management processes.

For detailed patch information, refer to the GitHub Security Advisory - GHSA-269q-hmxg-m83q and the Oracle Critical Patch Update - July 2022.

Workarounds

• Specify a custom temporary directory using the -Djava.io.tmpdir=/secure/path JVM argument pointing to a directory with restricted permissions
• Use DefaultHttpDataFactory.setBaseDir(...) to configure a custom directory that is only readable by the current user
• Ensure the custom directory has permissions set to 700 (owner read/write/execute only) on Unix-like systems
• Consider migrating away from Java 6 if still in use, as this vulnerability primarily affects older Java versions

# Configuration example
# Set a secure temporary directory when starting the JVM
java -Djava.io.tmpdir=/var/app/secure-tmp -jar your-netty-application.jar

# Create a secure temporary directory with proper permissions
mkdir -p /var/app/secure-tmp
chmod 700 /var/app/secure-tmp
chown appuser:appgroup /var/app/secure-tmp