CVE-2023-38408 involves the ssh-agent utility that comes with OpenSSH, an open-source suite of secure networking utilities that use the Secure Shell (SSH) protocol. This tool holds private keys used for public key authentication and can forward connections to other remote hosts. OpenSSH is commonly used for secure remote logins and file transfers over insecure networks.
What is CVE-2023-38408?
CVE-2023-38408, discovered by the Qualys Threat Research Unit, involves the ssh-agent forwarding feature. In a typical scenario, a system administrator (named Alice in this context) might run ssh-agent on her local workstation, then connect to a remote server via SSH, forwarding her ssh-agent. The attacker, having gained access to the remote server where Alice's ssh-agent is forwarded, could load (using dlopen()) and immediately unload (using dlclose()) any shared library in /usr/lib* on Alice's workstation.
How does CVE-2023-38408 work?
The exploit works even though ssh-agent is designed to load such libraries in a separate process (ssh-pkcs11-helper), not its own address space where private keys are stored. The reason this matters is that many shared libraries can have unintended side effects when loaded and unloaded, such as executing constructor and destructor functions.
The ssh-agent utility can be used in conjunction with an SSH jump host, also known as an SSH bastion host, which is an intermediary server through which SSH connections are made. This approach is often used in scenarios where direct SSH access to a target host is restricted for security reasons, and instead, all SSH connections must pass through the jump host.
Here's a typical scenario:
- On the local machine, start ssh-agent and add a private key using the ssh-add command.
- SSH to the jump host, forwarding the authentication agent connection. This would look something like this: ssh -A jumpuser@jumphost.
- From the jump host, SSH to the target host using the forwarded agent: ssh targetuser@targethost. The target connection uses the forwarded agent connection to authenticate, allowing a log in without storing the private key on the jump host.
This setup allows authentication to the target host using the private key without ever storing that key on the jump host. The -A flag enables agent forwarding.
However, it's worth noting that while this practice can be convenient, it also carries some security risks. When using agent forwarding, anyone with root access to the jump host can potentially use the SSH agent to authenticate to any other machine that trusts the key while the agent-forwarded connection is active.
Because of these risks, some organizations prefer other strategies for managing SSH access through a jump host, such as using ProxyJump or ProxyCommand configurations that create a tunnel through the jump host to the target host without the need for agent forwarding.
Is CVE-2023-38408 Significant?
This vulnerability is significant because it can allow a malicious actor to execute arbitrary code on a system using ssh-agent with the same privileges as the user running ssh-agent. This could potentially lead to compromise of the system, and potentially other systems that the compromised system can access.
The researchers at Qualys were able to chain together these side effects to achieve remote code execution in ssh-agent, overcoming security measures like Address Space Layout Randomization (ASLR), Position Independent Executables (PIE), and No eXecute (NX).
The advisory suggests that the issue can be reproduced on certain default installations of Ubuntu Desktop plus a few extra packages, and they believe other operating systems could be vulnerable as well.
Who should care about CVE-2023-38408?
While it would be unusual to find an IoT, ICS, medical, or even automotive device with an OpenSSH configuration using ssh-agent, we must remember that XoT is not just the single end device, but the overall ecosystem that supports it. In this case, organizations that appropriately segregate their XoT devices to limited access network segments will likely use an SSH jump host to access XoT segments. These jump hosts may be configured to use ssh-agent, making some component of these jump host interactions vulnerable to this attack.
How to easily detect vulnerable versions of OpenSSH
The Finite State Next Generation Platform pioneers a new age of SSH vulnerability detection through a sophisticated binary analysis approach. The methodology decomposes binary images into an array of subcomponents, including other binaries, third-party components, embedded software, drivers, kernels, board support packages (BSP), operating systems, and more, enabling the generation of Software Bill of Materials (SBOMs). This process leverages deep binary feature extraction and matching for efficient and precise binary image decomposition.
Following this setup, detecting vulnerable versions of OpenSSH with our Finite State Next Generation Platform becomes a simple process:
- Upload your specific OpenSSH binaries into Finite State.
- Finite State will return if CVE-2023-38408 and other vulnerabilities exist with the version of OpenSSH you uploaded
Want to learn more? Schedule a demo today and we'll show you how we can help eliminate this and other vulnerabilities.
Editor's Note: Edwin Shuttleworth also contributed to the research and writing of this report.
