GPU VulnDB

Database/Kernel, userspace & hypervisor

OpenSSH sshd: helper commands inherit sshd's supplemental groups, allowing privilege escalation

CVSS 7.0CVE-2021-41617Kernel, userspace & hypervisorcurated

Impact

When sshd is configured to run an AuthorizedKeysCommand or AuthorizedPrincipalsCommand helper as a different user, supplemental groups are not reinitialized, so the helper keeps the group memberships of the sshd process. Whoever controls that helper binary or its inputs gains the privileges those extra groups carry, which on a login or management node can mean access to group-owned keys, shared state, or files that gate wider access. This only bites sites that use these non-default directives, but those are exactly the central key-management setups common on HPC login nodes and bastion hosts - the hosts that front an entire GPU cluster. Exposure is limited to systems using that configuration; a stock sshd config is unaffected.

Who can reach it

Local user on the host, and only where sshd is configured with AuthorizedKeysCommand or AuthorizedPrincipalsCommand plus a differing AuthorizedKeysCommandUser / AuthorizedPrincipalsCommandUser. Requires an existing local account; attack complexity is rated high.

What to do

Upgrade to OpenSSH 8.8 or later (affected: 6.2 through 8.x before 8.8) or apply the distribution backport - SUSE, Debian LTS and Fedora have shipped updates per the referenced advisories - then restart sshd. Existing SSH sessions survive a restart, so no node drain is needed. As an interim mitigation, drop the AuthorizedKeysCommand / AuthorizedPrincipalsCommand directives or run the helper as the same user sshd runs as, and make sure sshd is not a member of privileged supplemental groups.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.