CVE-2023-38408: Remote Code Execution in OpenSSH’s forwarded ssh-agent

This is a breakdown of the exploit from the top comment of the hacker news thread on this bug, cleaned up by GPT 4.

This comment describes a complex and sophisticated security bug that exploits various characteristics of SSH agent forwarding, a feature provided by SSH (Secure Shell).

Here’s a simplified breakdown:

  1. Background: SSH agent forwarding allows an SSH client (Alice) to give an SSH server (Bob) the ability to use the client’s SSH credentials. This is done through a special protocol for communicating with the SSH agent.

  2. SSH_AGENTC_ADD_SMARTCARD_KEY bug: OpenSSH, a popular implementation of the SSH protocol, has a command (SSH_AGENTC_ADD_SMARTCARD_KEY) that allows a client to access a smart card (a kind of hardware security device) by loading a library using dlopen(). A security bug identified by Jann Horn in 2016 was that an SSH server could abuse this to make the SSH client load any library, including potentially malicious ones. OpenSSH fixed this bug by limiting which libraries could be loaded to a whitelist of safe directories.

  3. Qualys bug: Building on Horn’s bug, Qualys identified a new vulnerability. When OpenSSH loads a library for SSH_AGENTC_ADD_SMARTCARD_KEY and fails to find a required function (PKCS#11 entry point), it closes the library with dlclose(). However, many libraries do “cleanup” tasks during closing, such as unregistering callbacks and signal handlers. Some libraries don’t handle this correctly, and this can cause issues when they are loaded and unloaded in unexpected ways.

  4. Exploitation sequence: The attacker can force the client to load a library that registers a signal handler (like SIGBUS). This library is immediately closed because it doesn’t have the required function, but the signal handler remains registered. The attacker then loads another library, which overwrites the memory previously used by the signal handler. Finally, a third library is loaded that causes the SIGBUS signal. If the attacker can control the overwritten memory, they can execute arbitrary code.

  5. Address grooming with NODELETE: There’s an ELF flag called NODELETE that instructs the system not to unmap a library’s memory when it is closed. This can be used to “groom” the address space to make the exploitation more reliable.

  6. Executable stacks: Some libraries set another ELF flag that instructs the system to make the stack executable. If such a library is loaded, and the attacker has control over the program execution, they can inject and execute arbitrary code on the stack.

  7. Fuzzing to find exploitation sequences: The attacker can use a technique called “fuzzing” to automatically test many different sequences of library loads to find ones that lead to successful exploitation. The comment provides an example sequence of libraries that can be loaded to exploit the vulnerability.

  8. Other unexpected control transfers: The comment mentions that the researchers identified additional ways to gain control over the program execution using similar techniques.

  9. Heap-based buffer overflow: Finally, the researchers found a library that, when loaded, starts a server thread that listens on a TCP port. This server has a remotely exploitable heap-based buffer overflow vulnerability, providing yet another avenue for attack.

So, this comment is essentially describing a method of exploitation that relies on specific behaviors of libraries when they are loaded and unloaded, and how they interact with the memory space of the program and the system. It uses an initial vulnerability related to the loading of libraries to then cause a series of actions that ultimately result in the execution of arbitrary code.

Thanks for the notification.

I think this only has a risk for IPFire if the sswh server has had “Allow SSH Agent Forwarding” checked on the SSH menu page otherwise the server config file has AllowAgentForwarding no in it.

Either way, I have the build for the openssh-9.3p2 version in progress and it will be included in Core Update 177.


Reading about this a bit more it also looks like you would have to do your ssh agent forwarding from IPFire to an SSH server that is attacker controlled.


Update patch has been submitted to dev mailing list and patchwork.