Lurking vuln in SSH spec means every implementation must build patches.

A nasty vulnerability in a crucial bit of internet plumbing has emerged from the depths. Terrapin is a MitM attack on SSH—the secure shell protocol. German academic researchers discovered the flaw, but kept it secret until now, allowing SSH projects a head start to fix it.

Not an ideal time for most IT/DevOps shops to be rolling out patches. In today’s SB Blogwatch, we jingle bells.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Martian ’23.

Testy Testudine

What’s the craic? Zeljka Zorz reports—“SSH vulnerability exploitable”:

“Pushing out fixes”
Terrapin is a prefix truncation attack targeting the SSH protocol. … Aside from downgrading the SSH connection’s security by forcing it to use less secure client authentication algorithms, the attack can also be used to exploit vulnerabilities in SSH implementations.
…
The researchers have contacted nearly 30 providers of various SSH implementations and shared their research so they may provide fixes before publication. … But it will take a while for all clients and servers out there to be updated.
…
Vendors/maintainers of affected implementations, applications and Linux distros have been pushing out fixes, [including] AsyncSSH, LibSSH, OpenSSH, PuTTY, Transmit, SUSE … Dropbear SSH, Rust SSH, Thrussh, Paramiko, and libssh2.

Want more detail? Bill Toulas has your back—“Terrapin attacks can downgrade security”:

“Both the client and the server”
Terrapin … manipulates sequence numbers during the handshake process to breaks the SSH channel integrity when certain widely-used encryption modes are used. This … lets attackers remove or modify messages exchanged through the communication channel, which leads to downgrading the public key algorithms used for user authentication or disabling defenses against keystroke timing attacks.
…
Researchers from the Ruhr University Bochum developed the Terrapin attack … identified as CVE-2023-48795. [It] lowers the security of the established connection by truncating important negotiation messages without the client or server noticing it.
…
One solution is to implement a strict key exchange that makes package injection during the handshake unattainable. [But it] is only effective when implemented on both the client and the server.

Horse’s mouth? Fabian Bäumer, Marcus Brinkmann und Jörg Schwenk—“Terrapin Attack”:

“AES-GCM (RFC5647) is not affected”
SSH is an internet standard that provides secure access to network services, particularly remote terminal login and file transfer. … Terrapin breaks the integrity of SSH’s secure channel … without the client or server noticing it … by truncating the extension negotiation message (RFC8308) [which] can lead to using less secure client authentication algorithms.
…
Terrapin applies to most real-world SSH sessions. … In practice, our attack can be applied against any connection using either ChaCha20-Poly1305 or any CBC-mode cipher in combination with the Encrypt-then-MAC paradigm. … If your SSH implementations supports (and is configured to offer) the [email protected] encryption algorithm, or any encryption algorithm suffixed -cbc in combination with any MAC algorithm suffixed [email protected], you are vulnerable.
…
If you feel uncomfortable waiting for your SSH implementation to provide a patch, you can workaround this vulnerability by temporarily disabling the affected … algorithms in the configuration of your SSH server or client. … AES-GCM (RFC5647) is not affected by Terrapin as it does not use the SSH sequence numbers. Instead, AES-GCM uses the IV obtained from key derivation as its nonce.

Clever stuff. tptacek facepalms, furiously:

Lest we forget, this is a vulnerability in the protocol spec itself—not merely in one implementation. As Skrillor explains:

This vulnerability is notoriously hard to patch because it resides deep within the specification. Strict key exchange makes incompatible changes to the message and sequence number handling and is, therefore, locked behind an indicator string. If and only if both peers signal support for strict key exchange, the countermeasure can take effect.

And Ozzard agrees:

Protocol bugs: Always the hardest to fix. Lovely attack — props to the folks discovering it. Looks like I have a busy Christmas patching a very large number of systems.

Happy holidays, IT and DevOps. Pentium100 reminds us of the other option:

Disable that algorithm, I guess.

There might be wider implications. But u/CryptoOGkauai sees the silver lining:

The gist of it is: If you’re still using CBC ciphers instead of CTR ciphers for your AES256 SSH encryption then you’re going to get rekt. Get rid of CBC ciphers and you’re good, which has been best practice for a while.

Meanwhile, AnomalousBit brings us this uncomfortable mental image:

Yep you heard it too: The sound of thousands of ****holes clenching in unison.

And Finally:

The boxheads’ year

CW: Smoking, spiders, snakes, Shakira.

Previously in And Finally

You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi, @richij or [email protected]. Ask your doctor before reading. Your mileage may vary. Past performance is no guarantee of future results. Do not stare into laser with remaining eye. E&OE. 30.

Image sauce: Florida State Parks (public domain; leveled and cropped)