Terrapin Attack

• Paper
• Vulnerability Scanner
• Q&A
• Patches

Due to the widespread adoption of affected cipher modes, patching Terrapin (CVE-2023-48795) is notoriously difficult. To make matters worse, "strict kex" requires both peers, client and server, to support it in order to take effect. A wide variety of SSH implementations started adopting "strict kex" since public disclosure. This site is an attempt to capture affected products, and their patched release versions (if any).

All implementations marked with an asterisk were contacted as part of our responsible disclosure. You may also find the reasoning for this selection further down below.

We advise users of Win32-OpenSSH (the SSH implementation built into Windows 10 / 11 / Server 2019 / 2022) to update their implementations to 9.5.0.0p1-Beta manually as Microsoft stated that they won't be delivering this update through Windows Update. While it is true that the impact on Win32-OpenSSH is limited (and obviously doesn't hit Microsoft's bar for servicing), we must stress that "strict kex" requires both peers to support it. Microsoft's decision consequently allows unknown server-side implementation bugs to remain exploitable in a Terrapin-like attack, even if the server got patched to support "strict kex".

This list may not be complete. If you find any implementation that is not listed but has released support for "strict kex", feel free to open up a PR over on GitHub.

There are also open issues for the following SSH implementations referencing Terrapin (CVE-2023-48795). Note that listing an implementation here does not imply that Terrapin will affect the implementation. Instead, this is meant to keep track of implementations, which might implement "strict kex" in the future.

• KiTTY: cyd01/KiTTY#520
• Twisted Conch SSH: twisted/twisted#12057

Aside from the SSH implementations marked with an asterisk, we included the following implementations, vendors, and CERTs in our responsible disclosure process. Due to the lack of proper security contacts and response, we were not able to disclose our findings to some of them.

• Amazon AWS
• CERT-Bund
• Cisco
• Ericsson
• Microsoft
• Mikrotik
• Partnered CERTs of CERT-Bund (via CERT-Bund)
• SSH Server for Windows (Georgia Softworks)
• Termius (Termius Corporation)

The selection of SSH implementations contacted during responsible disclosure was based on several factors. We aimed to achieve a decent coverage of "strict kex" on public disclosure by focusing on the underlying SSH implementations. We gathered all SSH implementations listed in publicly available resources (Wikipedia SSH clients, Wikipedia SSH servers, Quendi SSH implementation comparison) as a baseline. We complemented these with potentially vulnerable implementations from our internet-wide SSH scans and some implementations that were well-known to us and not included in either of these lists. Based on this dataset, we contacted all implementations that fulfilled the following criteria:

1. Not based on another implementation already included, or heavily modified.
2. Supports chacha20-poly1305@openssh.com or any -etm@openssh.com algorithm.
3. Supports SSH extension negotiation (RFC8308).