HelpnetSecurity

Locking your ssh-agent exposed local-only keys until OpenSSH 10.5


Lock your ssh-agent and it should sit there refusing to sign anything until you unlock it. In OpenSSH 10.4, locking it also switched off the check that tells the agent whether a request came from your own machine or arrived down a forwarded connection from a remote server. The fix shipped today in OpenSSH 10.5.

The agent holds your decrypted private keys so you are not retyping a passphrase every few minutes, and agent forwarding lets a program on a remote host borrow those keys to sign a login. To keep the two cases apart, ssh sends a session-bind@openssh.com request that identifies a forwarded agent.

A locked agent refused those requests, and a request that never gets bound looks local. Operations meant to be limited to local use could then be performed remotely, including adding PKCS#11 tokens and using keys carrying destination restrictions, which say a key may only be used to reach one particular host. Someone who locked the agent before stepping away from the laptop made it more permissive, not less.

Two other security fixes

OpenSSH 10.5 also fixed a potential use-after-free around a realloc in the ssh client. The client can reach it when a remote forwarding is added through the local session multiplexing socket, the channel that lets several ssh sessions share one connection, while a remote forwarding open request is still pending with the server.

A researcher found that the “restrict” keyword in authorized_keys, the catch-all that is supposed to switch off every forwarding feature for a key, was not applying to tunnel forwarding. Tunnels are administratively disabled by default, so an administrator has to have turned them on for this one to bite.

Releases are going to come more often

Security bug reports have arrived in large numbers recently, “many of which are findings from AI models or made with AI assistance.” Plenty of those carry no security impact once a realistic threat model is applied. The team welcomes them anyway, and wants human triage, analysis, test cases and proposed fixes alongside them.

What changed the release schedule is a run of cases where a bug first flagged this way was later found independently by a different researcher, which suggests that adversaries who report nothing to open source projects can find these bugs too. Rather than batching fixes until the next planned release, the project will for now push them out sooner.

sshd now compares a public key’s type against the allowed algorithms before it parses the key the peer sent, which pulls at least some parsing and verification code out of reach of clients that have not authenticated yet. The release also repairs double frees in ssh-keygen that were impossible to reach outside a test harness.

Elsewhere in the release, “ssh -Z user@host” prints the keys the client will try for public key authentication, in order. ssh now prefers FIDO keys that need no touch and leaves keys that require a PIN or biometric verification for last. ssh-keygen can set or clear the touch-required and verify-required flags on FIDO private keys while resetting a passphrase.

Portable OpenSSH now requires ECC support, including the NISTP521 curve, from whatever libcrypto it is built against. LibreSSL, OpenSSL, BoringSSL and AWS LC all ship it in their default builds, and the –without-openssl configuration is not affected.



Source link