wolfSSH Patches 5 Security Vulnerabilities, Including Critical SSH Authentication Bypass

The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.

wolfSSH does not verify that the ECDSA curve identifier in a KEXDH_REPLY host-key blob matches the algorithm negotiated during key exchange. In ParseECCPubKey() the blob algorithm string is turned into a curve via NameToId and wcPrimeForId without comparison to ssh->handshake->pubKeyId, and the RFC 5656 curve identifier is discarded with GetSkip(). An active network man-in-the-middle can substitute a host-key blob on a different ECDSA curve for which the attacker holds the private key, so signature verification succeeds and the client accepts the wrong host key. This affects wolfSSH clients whose public-key callback is lax, such as trust-on-first-use, an algorithm-name-only check, or a fingerprint of the already-parsed key; the advisory does not name versions. No public proof of concept is known and the issue is not in CISA KEV.

Do: Apply the wolfSSL-published wolfSSH fix as soon as it is available for your build, and until then require a strict host-key check that binds the accepted key to the negotiated algorithm and curve rather than trusting the parsed blob alone. Do not rely on trust-on-first-use, algorithm-name-only callbacks, or fingerprints computed from the already-parsed key. Prefer a pinned known host key and treat any unexpected ECDSA curve change as a failed authentication.

The Windows port of wolfSSHd fails to release the Windows logon token from one authenticated session before acquiring a token for the next connection when password or public-key authentication is used. A less-privileged user who already has a valid account on the server can use that leftover token so a later connection is logged on as a more privileged user. Impact is full compromise of the higher-privileged account's access (confidentiality, integrity, and availability) on that host. Only Windows builds of wolfSSHd from the initial Windows port in wolfSSH 1.4.15 through 1.5.0 are affected; non-Windows builds are not. It is not listed in CISA KEV and no public proof-of-concept is known.

Do: Upgrade the Windows port of wolfSSHd to a wolfSSH release newer than 1.5.0 as soon as the vendor fix is available, and treat every Windows host running wolfSSHd 1.4.15 through 1.5.0 as affected. Until patched, restrict which local accounts may authenticate to wolfSSHd and review recent sessions for logons that do not match the connecting user. Non-Windows builds do not need this change.