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 HADOOP_HOME/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.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - 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 HADOOP_HOME/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. (CVE-2023-26031)

ID	Name	Product	Family	Type	Severity
413023	SCA: security update for org.apache.hadoop:hadoop-yarn-project (GHSA-94jh-j374-9r3j)	Tenable Cloud Security	SCA Checks	Local	high
413023	SCA: security update for org.apache.hadoop:hadoop-yarn-project (GHSA-94jh-j374-9r3j)	Tenable Self-Hosted Container Security	SCA Checks	Local	high

Detections

Analytics

CVE-2023-26031

high

Tenable Plugins

high

high