On November 30, 2023, a security flaw was discovered in OpenSSH’s ssh-agent. Assigned CVE-2023-51384, this vulnerability affects OpenSSH versions before 9.6, allowing sensitive private keys to lose important security protections when using PKCS#11 hardware tokens. But what does that mean, and why should you care? Let’s break it down in plain English.

What is ssh-agent?

ssh-agent is a program that makes it easier—and safer—to use SSH keys by holding your private keys in memory. If you use SSH to connect to servers, ssh-agent lets you type your password once when you add your key, and then handle SSH connections transparently for you.

“Destination constraints” are a safety feature—like seat belts for your SSH keys—preventing keys from being used with unauthorized hosts.

Understanding Destination Constraints

Normally, you can tell ssh-agent to lock down a specific private key, allowing it to be used only when connecting to a trusted destination—for example, only for github.com or your internal servers.

Example (restricting a key to github.com)

ssh-add -h github.com ~/.ssh/id_rsa

With this setup, even if someone hijacks your SSH agent socket, they can’t use your key to connect to other sites. Pretty neat, right?

The PKCS#11 Integration Flaw

Now, let’s talk about PKCS#11. It’s a standard for using hardware tokens (smartcards, YubiKeys, etc.) with SSH. When you run:

ssh-add -h some-server.com /usr/lib/opensc-pkcs11.so

ssh-agent asks the hardware token for available keys, and loads them all at once.

But in OpenSSH versions before 9.6, destination constraints like -h only get applied to the very first key coming from the token—not to the rest. All other keys are added completely unprotected!

Why is this bad?

If your token provides, say, 3 SSH keys, only one of them is protected with your destination constraint. The others are open to abuse—if someone accesses your ssh-agent, they can use those keys wherever they like.

How the Vulnerability Occurs (with Code Example)

Suppose your smartcard (YubiKey or similar) has keys for alice@github, bob@company, and carol@personal.

Say you run

ssh-add -h myserver.com /usr/lib/opensc-pkcs11.so

Expected Result:
All three keys should only work with myserver.com.

Actual Result in vulnerable OpenSSH:
Only the _first_ key (say, alice@github) is protected with the destination constraint. The others (bob@company and carol@personal) are added *without any restriction*.

Reviewing the Code

The bug lives in the loop that loads keys from the PKCS#11 module.

A simplified (pseudocode) example

for each key in PKCS#11_token {
    if (first_key) {
        apply_constraints(); // destination constraint gets set only here
    }
    add_key_to_agent();
}

The logic intended to apply the constraint to all keys, but the implementation was flawed—it only did so for the first one.

Exploiting CVE-2023-51384

Attackers who compromise your ssh-agent—for example, through a local privilege escalation or malware—can use the unprotected keys to authenticate to *any* server you have access to. The intended destination-only lock simply doesn’t exist for most of your hardware token keys.

Example Exploit

Suppose an attacker gets local access (e.g., malicious coworker, malware) and can talk to your running ssh-agent.

Using ssh-agent tooling, they can enumerate all keys

ssh-add -l

Then, the attacker can use unrestricted keys to connect to any server

ssh -i extracted_key someevilhost.com

Or, by forwarding your agent, simply let remote attackers abuse your credentials.

What You Should Do

If you use hardware tokens with SSH and destination constraints, you must upgrade OpenSSH to version 9.6 or newer.

- OpenSSH 9.6 Release Notes

Always double-check by running ssh -V.

Until you patch, avoid using agent constraints and be extra careful with your agent socket.

References

- NVD Entry for CVE-2023-51384
- OpenSSH Release Notes
- OpenSSH SSH-Add Manual
- Security Notice in OpenSSH 9.6
- PKCS#11 Standard

Closing Thoughts

CVE-2023-51384 is a subtle but powerful security bug. Using destination constraints with PKCS#11 tokens didn’t secure all your keys until OpenSSH 9.6. If you rely on SSH agent protections, don’t ignore this update. Upgrade now and be sure your digital seatbelts actually work!

Timeline

Published on: 12/18/2023 19:15:08 UTC
Last modified on: 01/05/2024 18:15:29 UTC