CVE-2024-23454: Apache Hadoop Information Disclosure Flaw

CVE-2024-23454 Overview

CVE-2024-23454 affects Apache Hadoop's RunJar.run() method, which fails to set restrictive permissions on the temporary directory it creates. On Unix-like systems, the system temporary directory is shared across all local users. Files written there without explicit POSIX permissions inherit default permissions that allow other local users to read the contents. When Hadoop jobs unpack sensitive data into this directory, any local user on the same host can view it.

The issue is classified as [CWE-378: Creation of Temporary File With Insecure Permissions]. It is a local information disclosure flaw, not a remote code execution issue, and requires an attacker to already have a local account on the affected host.

Critical Impact

Local users on shared Hadoop hosts can read sensitive data written by other users' jobs through the world-readable temporary directory created by RunJar.run().

Affected Products

• Apache Hadoop (all versions prior to the fix referenced in HADOOP-19031)
• NetApp products bundling Apache Hadoop components (see NetApp Security Advisory NTAP-20241101-0002)
• Unix-like deployments where multiple users share a single host

Discovery Timeline

• 2024-09-25 - CVE-2024-23454 published to NVD and announced on the OpenWall OSS Security list
• 2024-11-01 - NetApp issues advisory NTAP-20241101-0002 covering bundled Hadoop components
• 2025-11-13 - Last updated in NVD database

Technical Details for CVE-2024-23454

Vulnerability Analysis

Apache Hadoop ships a utility class named RunJar that executes JAR files submitted to the cluster. As part of execution, RunJar.run() extracts the JAR contents into a working directory derived from the system temporary directory, typically /tmp on Linux. The method creates this working directory using standard Java file APIs without calling Files.setPosixFilePermissions() or equivalent to restrict access.

Because /tmp is shared and world-readable on Unix-like systems, any directory created there without an explicit chmod inherits permissions that allow other local accounts to traverse and read its contents. Hadoop jobs commonly stage configuration files, credentials, intermediate datasets, and unpacked JAR resources in this location. A local attacker on the same node can list and read these files while the job is running.

The vulnerability does not require authentication to the Hadoop cluster itself. It only requires shell access to a host where RunJar executes.

Root Cause

The root cause is a missing permissions assignment when RunJar.run() creates its working directory. The Java code relies on default umask behavior rather than explicitly setting owner-only POSIX permissions (0700). On multi-tenant Linux hosts, the default umask does not produce sufficiently restrictive permissions to protect job data from other local users.

Attack Vector

Exploitation is local. An attacker with an unprivileged shell account on a Hadoop worker, edge node, or gateway monitors /tmp for new directories created by the user running RunJar. The attacker then reads files inside the working directory during the job's execution window. No special tooling is required, only standard Unix commands such as ls, find, and cat.

The vulnerability does not enable code execution, write access, or denial of service. The impact is limited to confidentiality of data staged by RunJar. Refer to the Apache JIRA HADOOP-19031 ticket and the Apache mailing list thread for the upstream discussion and patch details.

Detection Methods for CVE-2024-23454

Indicators of Compromise

• Directories under /tmp created by Hadoop user accounts with permissions broader than 0700 (for example, 0755 or 0775)
• Unexpected ls, cat, find, or cp activity from local non-Hadoop accounts targeting paths matching /tmp/hadoop-* or /tmp/*RunJar*
• Access events on staged JAR contents by user IDs other than the job owner

Detection Strategies

• Audit file system access on Hadoop nodes with auditd rules monitoring read events under /tmp for paths created by the Hadoop service account
• Run periodic scans for directories in /tmp owned by Hadoop users where the group or world permission bits are set
• Correlate process telemetry for java ... RunJar invocations with subsequent file reads by unrelated user IDs

Monitoring Recommendations

• Forward auditd and shell command history from Hadoop hosts to a centralized logging platform for retention and search
• Alert on local privilege boundary violations where one user reads files created by another inside shared temporary directories
• Track changes to the Hadoop installation, core-site.xml, and hadoop.tmp.dir configuration to confirm the patched version is in use

How to Mitigate CVE-2024-23454

Immediate Actions Required

• Upgrade Apache Hadoop to a release that includes the fix from HADOOP-19031
• Inventory all hosts running RunJar and restrict interactive local access to trusted operators only
• Set hadoop.tmp.dir to a directory outside /tmp that is owned by the Hadoop service account with 0700 permissions
• Review historical job outputs in /tmp for sensitive data exposure and rotate any credentials that may have been staged there

Patch Information

The Apache Hadoop project addressed the issue in the commit referenced by HADOOP-19031. The patch updates RunJar.run() to create its working directory with owner-only POSIX permissions. Downstream vendors including NetApp have published advisories tracking the fix in their bundled distributions. Consult vendor documentation for the specific patched version applicable to your deployment.

Workarounds

• Configure hadoop.tmp.dir and java.io.tmpdir to point to a directory with 0700 permissions owned by the Hadoop service account
• Restrict shell access on Hadoop nodes so only the service account and administrators can log in locally
• Mount a dedicated, non-shared temporary filesystem for Hadoop workloads on multi-tenant hosts

# Configuration example: restrict Hadoop temporary directory permissions
sudo mkdir -p /var/lib/hadoop/tmp
sudo chown hadoop:hadoop /var/lib/hadoop/tmp
sudo chmod 0700 /var/lib/hadoop/tmp

# In core-site.xml
# <property>
#   <name>hadoop.tmp.dir</name>
#   <value>/var/lib/hadoop/tmp</value>
# </property>

# Pass a restricted java.io.tmpdir to the JVM
export HADOOP_OPTS="$HADOOP_OPTS -Djava.io.tmpdir=/var/lib/hadoop/tmp"