mod_sftp is affected by "Terrapin" Prefix Truncation Attacks in SSH Specification (CVE-2023-48795)

[0-wiz-0]

Is mod_sftp affected by the TerraPin attack, i.e. https://nvd.nist.gov/vuln/detail/CVE-2023-48795 ?

[Castaglia]

Yes, the SSH protocol supported by the mod_sftp module is affected by the Terrapin attack.

[Castaglia]

I find that the OpenSSH 9.6 release notes contain a very nice description of this Terrapin attack:

* ssh(1), sshd(8): implement protocol extensions to thwart the
   so-called "Terrapin attack" discovered by Fabian Bäumer, Marcus
   Brinkmann and Jörg Schwenk. This attack allows a MITM to effect a
   limited break of the integrity of the early encrypted SSH transport
   protocol by sending extra messages prior to the commencement of
   encryption, and deleting an equal number of consecutive messages
   immediately after encryption starts. A peer SSH client/server
   would not be able to detect that messages were deleted.

   While cryptographically novel, the security impact of this attack
   is fortunately very limited as it only allows deletion of
   consecutive messages, and deleting most messages at this stage of
   the protocol prevents user user authentication from proceeding and
   results in a stuck connection.

   The most serious identified impact is that it lets a MITM to
   delete the SSH2_MSG_EXT_INFO message sent before authentication
   starts, allowing the attacker to disable a subset of the keystroke
   timing obfuscation features introduced in OpenSSH 9.5. There is no
   other discernable impact to session secrecy or session integrity.

   OpenSSH 9.6 addresses this protocol weakness through a new "strict
   KEX" protocol extension that will be automatically enabled when
   both the client and server support it. This extension makes
   two changes to the SSH transport protocol to improve the integrity
   of the initial key exchange.

   Firstly, it requires endpoints to terminate the connection if any
   unnecessary or unexpected message is received during key exchange
   (including messages that were previously legal but not strictly
   required like SSH2_MSG_DEBUG). This removes most malleability from
   the early protocol.

   Secondly, it resets the Message Authentication Code counter at the
   conclusion of each key exchange, preventing previously inserted
   messages from being able to make persistent changes to the
   sequence number across completion of a key exchange. Either of
   these changes should be sufficient to thwart the Terrapin Attack.

   More details of these changes are in the PROTOCOL file in the
   OpenSSH source distribition.

I will be implementing the same mitigations in mod_sftp.

[Castaglia]

Fixes merged to master, and backported to the 1.3.8 branch. Thanks!

[pghmcfc]

Will there be new 1.3.8/1.3.9rc releases in the near future, or would it be worth my while to issue a patched update in Fedora in the meantime?

[Castaglia]

Will there be new 1.3.8/1.3.9rc releases in the near future, or would it be worth my while to issue a patched update in Fedora in the meantime?

@pghmcfc I made new releases soon after merging these changes in, expecting that distributions (and users) would be wanting/expecting them:

• https://github.com/proftpd/proftpd/releases/tag/v1.3.9rc2
• https://github.com/proftpd/proftpd/releases/tag/v1.3.8b

[pghmcfc]

@Castaglia, great, thanks! Should have looked at the main site first before asking!

[severach]

proftpd gets chacha20-poly1305 #456 for a month then Terrapin takes it away. aes-gcm #1330 is the only cipher that came through the battle with Bowser unscathed.

---

The new kex kex-strict-s-v00@openssh.com is good and needed for better SSH security. Unfortunately it does nothing to fix the Terrapin problem with CBC, ETM, and chacha20, even in the far future. It will be exploitable forever and security scanners will be powerless to stop it as the “good” version is indistinguishable from the “bad” version. Updated clients and servers will still still make insecure connections with old versions in the wild.

CBC and ETM aren’t a problem. CBC was replaced with CTR years ago. Legacy clients using CBC are also using E&M, still secure. CTR+ETM is broken by Terrapin but there’s no known way to exploit it. All MAC go away as we switch everything to AEAD.

The Register: SSH shaken, not stirred by Terrapin vulnerability

ChaCha20-Poly1305 is said to be "vulnerable and perfectly exploitable" by Terrapin due to the way sequence numbers are used in key derivation. There isn't a cryptographic weakness in this algorithm, just in the way it's used for SSH.
CBC-Encrypt-then-MAC (CBC-EtM) is also vulnerable and "probabilistically" exploitable, we're told, though depending on the implementation, the attack may fail. The CTR-Encrypt-then-MAC algorithm is vulnerable but isn't practically exploitable.

chacha20 is the problem. Even with the new kex chacha20-poly1305@openssh.com must be completely disabled on servers to prevent its use by clients without the new kex. New clients must move the old chacha20 to the end if they continue to support it at all. This takes us back to the AES monoculture and a great loss for the movement to AEAD.

chacha20-poly1305@openssh.com is permanently broken in SSH. The only solution is to deprecate the current chacha20 immediately and produce another chacha20 that is as secure against Terrapin as aes-gcm with or without the new kex. Of course all clients that implement the new chacha20 will also have the new kex. Security scanners can show accurate recommendations without having to guess what percentage of in the wild clients haven’t been updated to use the new kex.

[pghmcfc]

I'm wondering what would be the best approach to take for "Enterprise" distributions, e.g. proftpd in Fedora EPEL for RHEL 7 and 8 (EPEL for RHEL 9 has 1.3.8 so that's just a simple upgrade). I currently have patched versions of 1.3.5e and 1.3.6e in those really old distributions (patched for all previous security issues and some other bugs). I try to stick with the same base release version of proftpd in each distribution so as to avoid any possible regressions or behaviour changes when users receive updates. However, this one looks to be a bit more complicated. The existing mod_sftp in 1.3.6e doesn't even support extension negotiation after the initial key exchange so it's already lacking some countermeasures that Terrapin is attacking. I thought about just using mod_sftp from 1.3.8b but that uses some other proftpd APIs (e.g. pr_snprintf, pr_random_next, pr_config_alloc) that are not available in 1.3.6.

I can get 1.3.8b to build OK on these old systems but is it worth the risk of incompatibility?

I guess another possibility would be to document that mod_sftp is not enabled by default, note the issues with the implementation as-is and leave it at that?

[Castaglia]

@pghmcfc Interestingly, the Terrapin attack is best for downgrading security by specifically interfering with that extension negotiation message; this EXT_INFO extension negotiation message is used to indicate support for SHA2 digests of e.g. RSA keys, rather than just SHA1. So for old mod_sftp versions which don't implement EXT_INFO, one could argue that their lack of EXT_INFO support means there's nothing for Terrapin to downgrade. Similarly, those old mod_sftp versions lack implementations of the impacted ciphers (ChaChaPoly, the ETM MACs, etc). So while the old mod_sftp versions will have their issues, they may not vulnerable to the worst consequences of Terrapin.

[Castaglia]

@severach I've been wondering how to make mod_sftp able to require "strict KEX" support from clients, but in a conditional manner. Using SFTPClientMatch seems like a good route. Unfortunately, though, mod_sftp won't know whether the client indicates support for "strict KEX" until after it has received the first KEXINIT message from the client -- and many clients send their KEXINIT message after receiving the server's KEXINIT. And that means that we can't dynamically adjust the ciphers we propose to the client. At least not that way.

However, if we know the "fixed" (updated) client versions that implement "strict KEX", then maybe we can use SFTPClientMatch to enforce the use of "strict KEX" for those client versions, e.g.:

SFTPClientMatch ... requireStrictKex

This way, we know that if e.g. ChaChaPoly, or the ETM MACs, are used by these clients, the usage is done with the "strict KEX" mitigations in use.

One can already use SFTPClientMatch ... sftpCiphers ... sftpDigests ... to select which algorithms to offer, based on a client's version. So one could use this to not offer the Terrapin-impacted ciphers to older clients.