CVE-2023-28531: OpenSSH Privilege Escalation Vulnerability

CVE-2023-28531 Overview

CVE-2023-28531 is a vulnerability in OpenSSH's ssh-add utility that affects versions 8.9 through 9.2. The vulnerability occurs when smartcard keys are added to the SSH authentication agent (ssh-agent) without properly applying the intended per-hop destination constraints. This flaw allows smartcard-based SSH keys to be used more broadly than intended, potentially enabling unauthorized authentication to hosts that should have been excluded by destination constraints.

Critical Impact

Smartcard keys added via ssh-add bypass per-hop destination constraints, potentially allowing unauthorized access to SSH servers that should have been restricted by agent forwarding policies.

Affected Products

• OpenBSD OpenSSH (versions 8.9 to before 9.3)
• NetApp Brocade Fabric Operating System
• NetApp HCI Bootstrap OS
• NetApp SolidFire Element OS

Discovery Timeline

• 2023-03-15 - Vulnerability disclosed on Openwall OSS Security Discussion
• 2023-03-17 - CVE CVE-2023-28531 published to NVD
• 2025-11-04 - Last updated in NVD database

Technical Details for CVE-2023-28531

Vulnerability Analysis

This vulnerability represents an authorization bypass in OpenSSH's smartcard key handling. When users add smartcard keys to ssh-agent using the ssh-add command with destination constraints (introduced in OpenSSH 8.9), those constraints are not properly enforced. Destination constraints are a security feature designed to limit which hosts an SSH key can authenticate to when agent forwarding is in use, providing defense against agent hijacking attacks.

The issue specifically affects smartcard keys (such as those stored on hardware security devices like YubiKeys or PIV cards). When these keys are added to the agent with -h (destination constraint) options, the constraints are silently ignored, effectively granting the keys broader access than the user intended.

Root Cause

The root cause lies in the ssh-add implementation's handling of smartcard keys versus regular keys. When processing smartcard key additions, the code path fails to pass the destination constraint parameters to the agent. This results in smartcard keys being added with unrestricted permissions, bypassing the security boundaries that destination constraints are designed to enforce.

Attack Vector

The attack vector is network-based and exploits the missing destination constraints on smartcard keys. An attacker who has compromised a system where agent forwarding is in use could potentially leverage the forwarded smartcard key to authenticate to hosts that should have been excluded by destination constraints.

In a typical exploitation scenario:

1. A user adds a smartcard key with destination constraints intending to limit which hosts can use the key
2. Due to this vulnerability, the constraints are not applied
3. If the user connects to an untrusted intermediate host with agent forwarding enabled, an attacker on that host could use the forwarded key to access additional systems
4. The smartcard key can be used to authenticate to any accessible SSH server, not just the constrained destinations

The vulnerability requires agent forwarding to be enabled and an attacker to have access to a system in the SSH connection chain. While exploitation requires specific conditions, the potential for lateral movement in enterprise environments makes this a significant security concern.

Detection Methods for CVE-2023-28531

Indicators of Compromise

• Unexpected SSH authentication events from hosts that should have been excluded by destination constraints
• SSH agent forwarding logs showing smartcard key usage to non-permitted destinations
• Authentication patterns that indicate lateral movement beyond intended access boundaries

Detection Strategies

• Monitor SSH authentication logs for connections using smartcard keys to unexpected destinations
• Audit ssh-agent configurations and review which keys have been added without proper constraints
• Implement centralized logging for SSH sessions to identify potential unauthorized access patterns
• Review SSH agent socket access logs for signs of agent hijacking attempts

Monitoring Recommendations

• Enable verbose logging on SSH servers to capture key type and source information
• Deploy network monitoring to detect SSH connections to unexpected internal hosts
• Implement alerting for SSH connections that bypass expected network segmentation
• Regularly audit systems running affected OpenSSH versions in critical infrastructure

How to Mitigate CVE-2023-28531

Immediate Actions Required

• Upgrade OpenSSH to version 9.3 or later where the vulnerability has been patched
• Disable SSH agent forwarding where not strictly required (ForwardAgent no in SSH config)
• Review and minimize the use of agent forwarding on untrusted intermediate hosts
• Consider using ProxyJump instead of agent forwarding for multi-hop SSH connections

Patch Information

OpenSSH version 9.3 addresses this vulnerability by properly applying destination constraints to smartcard keys when they are added via ssh-add. System administrators should update to OpenSSH 9.3 or later. Several Linux distributions have released security advisories with patched packages:

• Fedora Package Announcement - Updated packages for Fedora
• Gentoo GLSA 202307-01 - Gentoo Linux security advisory
• Debian DSA-5586 - Debian security update
• NetApp Security Advisory - NetApp product advisories

Workarounds

• Avoid using ssh-add with smartcard keys until the system is patched; use direct smartcard authentication instead
• Disable agent forwarding globally by setting AllowAgentForwarding no on SSH servers
• Use SSH certificate authentication with principals to enforce destination restrictions at the server level
• Consider using jump hosts with ProxyJump configuration rather than agent forwarding

# SSH configuration to disable agent forwarding
# Add to /etc/ssh/sshd_config on servers
AllowAgentForwarding no

# Add to ~/.ssh/config on clients to prevent forwarding by default
Host *
    ForwardAgent no

# Use ProxyJump for multi-hop connections instead of agent forwarding
Host internal-server
    ProxyJump jump-host.example.com
    ForwardAgent no