A flaw was found in Apache hadoop. The WebHDFS client can send a SPNEGO authorization header to a remote URL without proper verification which could lead to an access restriction bypass. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
A vulnerability has been found in the way developers have implemented the archive extraction of files. An arbitrary file write vulnerability, that can be achieved using a specially crafted zip archive (affects other archives as well, bzip2, tar,xz, war, cpio, 7z), that holds path traversal filenames. So when the filename gets concatenated to the target extraction directory, the final path ends up outside of the target folder. Of course if an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue quite easily. This affects multiple libraries that lacks of a high level APIs that provide the archive extraction functionality.
References: https://snyk.io/research/zip-slip-vulnerability
Patch: https://github.com/apache/hadoop/commit/745f203e577bacb35b042206db94615141fa5e6f#diff-19cfa944d1bb9ce1daa46aa4223f3642
Out-of-bounds Write vulnerability in Apache Hadoop HDFS native client.
This issue affects Apache Hadoop: from 3.2.0 before 3.4.2.
Users are recommended to upgrade to version 3.4.2, which fixes the issue.
Relative library resolution in linux container-executor binary in Apache Hadoop 3.3.1-3.3.4 on Linux allows local user to gain root privileges. If the YARN cluster is accepting work from remote (authenticated) users, this MAY permit remote users to gain root privileges.
Hadoop 3.3.0 updated the " YARN Secure Containers https://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-site/SecureContainer.html " to add a feature for executing user-submitted applications in isolated linux containers.
The native binary HADOOPHOME/bin/container-executor is used to launch these containers; it must be owned by root and have the suid bit set in order for the YARN processes to run the containers as the specific users submitting the jobs.
The patch " YARN-10495 https://issues.apache.org/jira/browse/YARN-10495 . make the rpath of container-executor configurable" modified the library loading path for loading .so files from "$ORIGIN/" to ""$ORIGIN/:../lib/native/". This is the a path through which libcrypto.so is located. Thus it is is possible for a user with reduced privileges to install a malicious libcrypto library into a path to which they have write access, invoke the container-executor command, and have their modified library executed as root. If the YARN cluster is accepting work from remote (authenticated) users, and these users' submitted job are executed in the physical host, rather than a container, then the CVE permits remote users to gain root privileges.
The fix for the vulnerability is to revert the change, which is done in YARN-11441 https://issues.apache.org/jira/browse/YARN-11441 , "Revert YARN-10495". This patch is in hadoop-3.3.5.
To determine whether a version of container-executor is vulnerable, use the readelf command. If the RUNPATH or RPATH value contains the relative path "./lib/native/" then it is at risk
$ readelf -d container-executor|grep 'RUNPATH\|RPATH' 0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/:../lib/native/]
If it does not, then it is safe:
$ readelf -d container-executor|grep 'RUNPATH\|RPATH' 0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/]
For an at-risk version of container-executor to enable privilege escalation, the owner must be root and the suid bit must be set
$ ls -laF /opt/hadoop/bin/container-executor ---Sr-s---. 1 root hadoop 802968 May 9 20:21 /opt/hadoop/bin/container-executor
A safe installation lacks the suid bit; ideally is also not owned by root.
$ ls -laF /opt/hadoop/bin/container-executor -rwxr-xr-x. 1 yarn hadoop 802968 May 9 20:21 /opt/hadoop/bin/container-executor
This configuration does not support Yarn Secure Containers, but all other hadoop services, including YARN job execution outside secure containers continue to work.
Severity: low
Affected versions:
- Apache Hadoop before 3.4.0
Description:
Apache Hadoop’s RunJar.run() does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content. This is because, on unix-like systems, the system temporary directory is shared between all local users. As such, files written in this directory, without setting the correct posix permissions explicitly, may be viewable by all other local users.
This issue is being tracked as HADOOP-19031
Credit:
Andrea Cosentino (finder)
References:
https://issues.apache.org/jira/browse/HADOOP-19031 https://hadoop.apache.org/ https://www.cve.org/CVERecord?id=CVE-2024-23454 https://issues.apache.org/jira/browse/HADOOP-19031
Vulnerability in Apache Hadoop 0.23.x, 2.x before 2.7.5, 2.8.x before 2.8.3, and 3.0.0-alpha through 3.0.0-beta1 allows a cluster user to expose private files owned by the user running the MapReduce job history server process. The malicious user can construct a configuration file containing XML directives that reference sensitive files on the MapReduce job history server host.
The YARN NodeManager in Apache Hadoop 2.7.3 and 2.7.4 can leak the password for credential store provider used by the NodeManager to YARN Applications.
In Apache Hadoop versions 2.6.1 to 2.6.5, 2.7.0 to 2.7.3, and 3.0.0-alpha1, if a file in an encryption zone with access permissions that make it world readable is localized via YARN's localization mechanism, that file will be stored in a world-readable location and can be shared freely with any application that requests to localize that file.
In Apache Hadoop 2.x before 2.7.4, a user who can escalate to yarn user can possibly run arbitrary commands as root user.
This is an information disclosure vulnerability in Apache Hadoop before 2.6.4 and 2.7.x before 2.7.2 in the short-circuit reads feature of HDFS. A local user on an HDFS DataNode may be able to craft a block token that grants unauthorized read access to random files by guessing certain fields in the token.
In Apache Hadoop 3.0.0-alpha1 to 3.0.0, 2.9.0, 2.8.0 to 2.8.3, and 2.5.0 to 2.7.5, HDFS exposes extended attribute key/value pairs during listXAttrs, verifying only path-level search access to the directory rather than path-level read permission to the referent.
The YARN NodeManager in Apache Hadoop 2.6.x before 2.6.5 and 2.7.x before 2.7.3 can leak the password for credential store provider used by the NodeManager to YARN Applications.
Apache Hadoop before 0.23.4, 1.x before 1.0.4, and 2.x before 2.0.2 generate token passwords using a 20-bit secret when Kerberos security features are enabled, which makes it easier for context-dependent attackers to crack secret keys via a brute-force attack.
DataNodes in Apache Hadoop 2.0.0 alpha does not check the BlockTokens of clients when Kerberos is enabled and the DataNode has checked out the same BlockPool twice from a NodeName, which might allow remote clients to read arbitrary blocks, write to blocks to which they only have read access, and have other unspecified impacts.
Hadoop 1.0.3 contains a symlink vulnerability as a result of storing pid files in the shared /tmp directory by default.
The Kerberos/MapReduce security functionality in Apache Hadoop 0.20.203.0 through 0.20.205.0, 0.23.x before 0.23.2, and 1.0.x before 1.0.2, as used in Cloudera CDH CDH3u0 through CDH3u2, Cloudera hadoop-0.20-sbin before 0.20.2+923.197, and other products, allows remote authenticated users to impersonate arbitrary cluster user accounts via unspecified vectors.
It was reported [1] that:
"The Apache Hadoop RPC protocol is intended to provide bidirectional authentication between clients and servers. However, a malicious server or network attacker can unilaterally disable these authentication checks. This allows for potential reduction in the configured quality of protection of the RPC traffic, and privilege escalation if authentication credentials are passed over RPC."
This flaw only affects users who have enabled Hadoop's kerberos security features. This is corrected in upstream versions 0.23.9, 1.2.1, and 2.0.6-alpha.
[1] http://seclists.org/fulldisclosure/2013/Aug/251
The YARN NodeManager daemon in Apache Hadoop 0.23.0 through 0.23.11 and 2.x before 2.5.2, when using Kerberos authentication, allows remote cluster users to change the permissions of certain files to world-readable via a symlink attack in a public tar archive, which is not properly handled during localization, related to distributed cache.
Apache Hadoop 0.23.x before 0.23.11 and 2.x before 2.4.1, as used in Cloudera CDH 5.0.x before 5.0.2, do not check authorization for the (1) refreshNamenodes, (2) deleteBlockPool, and (3) shutdownDatanode HDFS admin commands, which allows remote authenticated users to cause a denial of service (DataNodes shutdown) or perform unnecessary operations by issuing a command.
The Hadoop connector 1.1.1, 2.4, 2.5, and 2.7.0-0 before 2.7.0-3 for IBM Spectrum Scale and General Parallel File System (GPFS) allows local users to read or write to arbitrary GPFS data via unspecified vectors.
Apache Hadoop 2.6.x encrypts intermediate data generated by a MapReduce job and stores it along with the encryption key in a credentials file on disk when the Intermediate data encryption feature is enabled, which allows local users to obtain sensitive information by reading the file.
In Apache Hadoop 2.6.x before 2.6.5 and 2.7.x before 2.7.3, a remote user who can authenticate with the HDFS NameNode can possibly run arbitrary commands with the same privileges as the HDFS service.
In Apache Hadoop 2.8.0, 3.0.0-alpha1, and 3.0.0-alpha2, the LinuxContainerExecutor runs docker commands as root with insufficient input validation. When the docker feature is enabled, authenticated users can run commands as root.
HDFS clients interact with a servlet on the DataNode to browse the HDFS namespace. The NameNode is provided as a query parameter that is not validated in Apache Hadoop before 2.7.0.
The HDFS web UI in Apache Hadoop before 2.7.0 is vulnerable to a cross-site scripting (XSS) attack through an unescaped query parameter.
In Apache Hadoop 2.7.4 to 2.7.6, the security fix for CVE-2016-6811 is incomplete. A user who can escalate to yarn user can possibly run arbitrary commands as root user.
Web endpoint authentication check is broken in Apache Hadoop 3.0.0-alpha4, 3.0.0-beta1, and 3.0.0. Authenticated users may impersonate any user even if no proxy user is configured.
In Apache Hadoop versions 3.0.0-alpha2 to 3.0.0, 2.9.0 to 2.9.2, 2.8.0 to 2.8.5, any users can access some servlets without authentication when Kerberos authentication is enabled and SPNEGO through HTTP is not enabled.
In Apache Hadoop 3.1.0 to 3.1.1, 3.0.0-alpha1 to 3.0.3, 2.9.0 to 2.9.1, and 2.0.0-alpha to 2.8.4, the user/group information can be corrupted across storing in fsimage and reading back from fsimage.
In Apache Hadoop 2.9.0 to 2.9.1, 2.8.3 to 2.8.4, 2.7.5 to 2.7.6, KMS blocking users or granting access to users incorrectly, if the system uses non-default groups mapping mechanisms.