Skip to main content

On 19th July 2023, OpenSSH released the release notes of OpenSSH 9.3p2, which addressed a Remote Code Execution Vulnerability in OpenSSH’s forwarded ssh-agent. The flaw is tracked as CVE-2023-38408 allows a remote attacker to potentially execute arbitrary commands on vulnerable OpenSSH’s forwarded ssh-agent. Since the flaw allows attackers to perform Remote Code Execution on the victim machine and its widespread use of OpenSSH’s forwarded ssh-agent, it is highly recommended to learn how to Fix CVE-2023-38408- a Remote Code Execution Vulnerability in OpenSSH’s forwarded ssh-agent. The Qualys Threat Research Unit (TRU) has been credited with the discovery of this vulnerability upon they reported the flaw on 7th July 2023.

Before we jump in to learn how to Fix CVE-2023-38408- a Remote Code Execution Vulnerability in OpenSSH’s forwarded ssh-agent, let’s see a short intro about the ssh-agent and its agent forwarding feature, why it is needed, and what are the benefits of the agent forward feature.

A Short Introduction to ssh-agent

ssh-agent is a key component of the SSH (Secure Shell) protocol suite and serves as an authentication agent. It operates as a background process, intended to aid in managing private keys associated with public key authentication.

The primary role of the ssh-agent is to store private keys, eliminating the need for users to repeatedly enter their passphrase when using SSH to connect to different servers. When a session starts, the user adds their private key(s) to the ssh-agent. After the key has been added, the ssh-agent manages the key, supplying it whenever necessary, without requiring the user to manually enter their passphrase each time.

While interacting with an ssh-agent, users initiate an SSH client program that communicates with the agent and requests operations like user authentication. The communication between the SSH client and the agent is facilitated by a Unix-domain socket, secured by the operating system.

One notable feature of ssh-agent is ‘agent forwarding’. This allows an ssh-agent’s services to be forwarded to a remote system, via an SSH protocol connection. This essentially means that when you’re connected to a remote server, you can use your local ssh-agent to perform authentication tasks, without storing any private keys on the remote system. It’s a convenient feature but requires careful usage due to its potential security implications.

Some key points about ssh-agent:

  • It stores the decrypted private keys in memory rather than on disk, avoiding the need to enter passphrases repeatedly.
  • Keys are added to the agent using the ssh-add command.
  • The agent generates a UNIX socket that programs can use to communicate with it.
  • The SSH_AUTH_SOCK environment variable points to this socket.
  • Agent forwarding (-A option) allows remotely connecting to servers using the keys stored in the local ssh-agent rather than leaving keys on remote hosts.
  • When agent forwarding is used, the local ssh-agent’s socket is exposed on the remote server.
  • So in summary, ssh-agent is a key manager for SSH authentication that allows agent forwarding to avoid storing keys on remote hosts. But care must be taken in how it handles requests to avoid security issues.

    What is the Need for Agent Forwarding?

    Agent forwarding is a prominent feature of the SSH (Secure Shell) protocol that enhances the convenience and efficiency of managing secure connections between different systems. It is an integral part of the ssh-agent utility.

    In a typical SSH connection, a user connects from a local system to a remote system by entering their passphrase to unlock their private key, which is then used for authentication. However, if the user needs to establish an SSH connection from the remote system to another system, they would have to supply their passphrase again to unlock their private key, which can be cumbersome and pose security risks, especially if the remote system is not fully trusted.

    This is where agent forwarding comes into play. Agent forwarding allows users to leverage their local ssh-agent on a remote system. This means that the private key used for authentication stays on the local machine and does not need to be stored on any remote system.

    When a user establishes an SSH connection with agent forwarding enabled, the local ssh-agent creates a socket on the remote system. This socket serves as a forwarding channel, allowing the remote system to communicate with the local ssh-agent for operations requiring the user’s private key.

    As a result, when a user initiates a subsequent SSH connection from the remote system to another system, the authentication request is forwarded back to the local ssh-agent. The local ssh-agent then handles the authentication using the stored private key, and the user doesn’t need to enter their passphrase again.

    While agent forwarding significantly simplifies the handling of SSH connections and private keys, it should be used with caution due to potential security risks. If a malicious actor gains control over a remote system where agent forwarding is used, they could potentially use the forwarding channel to perform operations with the user’s private key. Therefore, agent forwarding is recommended only for trusted systems and secure networks.

    Reasons to have Agent Forwarding are:

    • Keys are not exposed on remote hosts where they could be compromised if the server is breached. The private keys stay on your local machine only.
    • You don’t have to manage copying keys to multiple hosts or keep track of passphrases in multiple places. The keys in your local ssh-agent are available to all remote connections.
    • Changing a passphrase or key only needs to be done in one place – your local ssh-agent. Without forwarding, any change would need to be reflected across all the remote servers with a copy of the key.
    • Revoking a compromised key is easier by just removing it from your local ssh-agent rather than having to find and remove copies on all accessible hosts.
    • Agent forwarding allows SSH connections to “hop” through intermediate servers to reach the destination. So you don’t need direct ssh access or key distribution to all servers.

    Benefits of Using the Agent Forwarding

    This utility becomes indispensable in environments where users need to interact with multiple systems using SSH public key authentication.

    Let’s explore some key reasons that necessitate the use of agent forwarding:

    1. Ease of Handling Multiple Connections: If a user needs to hop from one system to another via SSH (a process known as SSH chaining), agent forwarding saves the user from the hassle of repeatedly entering their passphrase. This is particularly useful in networked environments where system administrators frequently need to access multiple servers.
    2. Improved Security: With agent forwarding, private keys remain on the local system and are never transferred or stored on remote machines. This reduces the risk associated with exposing private keys on potentially less secure systems.
    3. Automation and Scripting: Agent forwarding can be instrumental in automation tasks or scripts that require frequent server connections. Because it eliminates the need for manual passphrase input or insecure password storage, scripts can run more smoothly and securely.
    4. Convenience: Agent forwarding offers an additional level of convenience for users, as they do not have to worry about managing and securing private keys on multiple systems. They can authenticate seamlessly across several systems using a single local ssh-agent.

    Summary of the CVE-2023-38408 Vulnerability

    The CVE-2023-38408 vulnerability is a Remote Code Execution Vulnerability in OpenSSH’s forwarded ssh-agent. This vulnerability was uncovered by the Qualys Threat Research Unit (TRU), which specializes in identifying and analyzing various security vulnerabilities.

    The main issue with this vulnerability is that it allows a remote attacker to execute arbitrary commands on systems running the vulnerable version of OpenSSH’s forwarded ssh-agent. This means that a hacker could potentially take control of a system and perform unauthorized actions.

    This vulnerability poses a significant risk due to the widespread use of OpenSSH’s forwarded ssh-agent in many networked systems, particularly within Unix-based environments like Linux. OpenSSH is a critical tool used for securely accessing remote machines, and the ssh-agent forwarding feature is often utilized to handle authentication details when making multiple SSH connections.

    Qualys team said that were able to independently verify this vulnerability and even developed a Proof of Concept (PoC) exploit on certain installations of Ubuntu Desktop (versions 22.04 and 21.10). They suspect that this vulnerability would be existing in other Linux distributions.

    We recommend seeing the complete technical details of the CVE-2023-38408 vulnerability here. Well, the attack vector and CVSS scores are yet to analyze.

    OpenSSH Versions Vulnerable to CVE-2023-38408

    The flaw affects all the versions, which are equal to and lower than v9.3p2.. Please check the version of OpenSSH that your machine is running. Run this command to check the OpenSSH version.

    ssh -V
    Check the OpenSSH version

    In this case, we have OpenSSH v9.2p1 on our server, which is vulnerable.

    How to Fix CVE-2023-38408- A Remote Code Execution Vulnerability in OpenSSH’s forwarded ssh-agent?

    OpenSSH has responded to this vulnerability by rolling out a patched version of OpenSSH. This Remote Code Execution Vulnerability in OpenSSH’s forwarded ssh-agent is fixed in OpenSSH v 9.3p2. We suggest finding out the current version of OpenSSH on your machines and upgrading to v9.3p2.

    Time needed: 10 minutes

    How to Fix CVE-2023-25136?

    The installation process is quite simple if your distribution has a compelled version of OpenSSH-server. If not, you may need to download the package and compel the package using make and install it using the make install commands.

    1. Check the OpenSSH version

      Run this command to check the version of OpenSSH:

      $ ssh -V

      Check the OpenSSH version

    2. Download the latest OpenSSH package

      Download the latest package. In this case, since we have OpenSSH v9.2p1 which is vulnerable to this flaw, we need to download v9.3p2.

      $ wget

    3. https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.3p2.tar.gz
      $ chmod +x openssh-9.3p2.tar.gz

      Download the latest OpenSSH package

    4. Extract the OpenSSH package

      Extract the downloaded package to a folder and change it into the extracted directory.

      $ tar -xf openssh-9.3p2.tar.gz
      $ cd openssh-9.3p2/

      Extract the OpenSSH package

    5. Manually compile OpenSSH

      Run ./configure to configure the build settings for your system architecture. If you want to enable PAM and SELinux support, add the –with-pam and –with-selinux flags respectively. Just make sure you have all the necessary header files for them to work.

      $ sudo apt install libpam0g-dev libselinux1-dev
      $ ./configure --with-md5-passwords --with-pam --with-selinux --with-privsep-path=/var/lib/sshd/ --sysconfdir=/etc/ssh

      Manually compile OpenSSH

    6. Install/upgrade OpenSSH

      Install or upgrade the OpenSSH build using make and make install commands

      $ make
      $ make install

      Note: You may need to install make and gcc utilities before you install or upgrade the OpenSSH.

      Run this command to install the required packages if not preinstalled.

      $ sudo apt install make gcc

      Installupgrade OpenSSH

    7. Check the OpenSSH version after the installation process gets completed

      Run this command to check the version of OpenSSH:

      $ ssh -V

      Check the OpenSSH version after the installation process gets completed

    How to Fix the “configure: error: no acceptable C compiler found in $PATH” Error?

    If you get configure: error: no acceptable C compiler found in $PATH error when you try compile the before building any source code, then no gcc compiler is installed on your computer or gcc compiler is not set to $PATH veritable. One simple solution to this problem is to install build-essential or development tools on your server.

    To install gcc use this: (run as root)

    Redhat base:

    yum groupinstall "Development Tools"

    Debian base:

    apt-get install build-essential

    openSUSE base:

    zypper install --type pattern devel_basis

    Alpine:

    apk add build-base

Leave a Reply