Re: Terrapin

[Brian Pence <bpence%celestialsoftware.net@localhost>]

From the OpenSSH PROTOCOL document:

1.10 transport: strict key exchange extension

OpenSSH supports a number of transport-layer hardening measures under
a "strict KEX" feature. This feature is signalled similarly to the
RFC8308 ext-info feature: by including a additional algorithm in the
initial SSH2_MSG_KEXINIT kex_algorithms field. The client may append
"kex-strict-c-v00%openssh.com@localhost" to its kex_algorithms and the server
may append "kex-strict-s-v00%openssh.com@localhost". These pseudo-algorithms
are only valid in the initial SSH2_MSG_KEXINIT and MUST be ignored
if they are present in subsequent SSH2_MSG_KEXINIT packets.

When an endpoint that supports this extension observes this algorithm
name in a peer's KEXINIT packet, it MUST make the following changes to
the protocol:

a) During initial KEX, terminate the connection if any unexpected or
   out-of-sequence packet is received. This includes terminating the
   connection if the first packet received is not SSH2_MSG_KEXINIT.
   Unexpected packets for the purpose of strict KEX include messages
   that are otherwise valid at any time during the connection such as
   SSH2_MSG_DEBUG and SSH2_MSG_IGNORE.
b) After sending or receiving a SSH2_MSG_NEWKEYS message, reset the
   packet sequence number to zero. This behaviour persists for the
   duration of the connection (i.e. not just the first
   SSH2_MSG_NEWKEYS).

Brian Pence

Celestial Software

901-283-1970

http://www.celestialsoftware.net

On Wed, Dec 27, 2023 at 9:08 AM Brian Pence <bpence%celestialsoftware.net@localhost> wrote:

And at least one claim that some implementations knew about this about a month before public disclosure, so they were working on 'strict kex' for a while.

This protocol vulnerability was pre-disclosed to us by Fabian Bäumer, Marcus Brinkmann, and Jörg Schwenk, on 17 November 2023. For full details of their report, see their dedicated website about the Terrapin attack.

Brian Pence

Celestial Software

901-283-1970

http://www.celestialsoftware.net

On Wed, Dec 27, 2023 at 9:06 AM Brian Pence <bpence%celestialsoftware.net@localhost> wrote:

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,

Then each of the 'fixed' packages will have some kind of documentation describing their use of 'strict kex'

For example putty 0.80:

https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/vuln-terrapin.html

To mitigate the vulnerability, the OpenSSH project has defined a SSH extension called 'strict KEX' (documented in their PROTOCOL document), which PuTTY 0.80 implements.

Brian Pence

Celestial Software

901-283-1970

http://www.celestialsoftware.net

On Mon, Dec 25, 2023 at 1:58 AM Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost> wrote:

Brian Pence <bpence%celestialsoftware.net@localhost> writes:

>Related publication at NIST: https://nvd.nist.gov/vuln/detail/CVE-2023-48795
>
>Implementation versions that are identified as NOT VULNERABLE have all
>recently implemented "strict key exchange"

Where are you seeing that?  I can't find that text anywhere on the page.

Peter.