Terrapin SSH Attack

dennypage

had you disabled etm? when you disabled chacha..

No. I only have -etm MACs enabled. I have other things disabled (RSA), which is why I asked about other mitigating factors.

dennypage

@dennypage This is the security patch I have historically applied for ssh:

--- /etc/inc/globals.inc.org	2023-02-02 08:47:26.000000000 -0800
+++ /etc/inc/globals.inc	2023-02-02 22:53:00.000000000 -0800
@@ -365,7 +365,6 @@
 
 global $ssh_keys;
 $ssh_keys = [
-	['type' => 'rsa', 'suffix' => 'rsa_'],
 	['type' => 'ed25519', 'suffix' => 'ed25519_'],
 ];
 
--- /etc/sshd.org	2023-02-02 08:47:26.000000000 -0800
+++ /etc/sshd	2023-02-02 22:53:00.000000000 -0800
@@ -70,7 +70,7 @@
 /* Include default configuration for pfSense */
 /* Taken from https://stribika.github.io/2015/01/04/secure-secure-shell.html */
 $sshconf = "# This file is automatically generated at startup\n";
-$sshconf .= "KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256\n";
+$sshconf .= "KexAlgorithms curve25519-sha256@libssh.org,curve25519-sha256\n";
 /* Run the server on another port if we have one defined */
 $sshconf .= "Port $sshport\n";
 /* Only allow protocol 2, because we say so */
@@ -116,7 +116,7 @@
 }
 $sshconf .= "X11Forwarding no\n";
 $sshconf .= "Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr\n";
-$sshconf .= "MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com\n";
+$sshconf .= "MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com\n";
 $sshconf .= "# override default of no subsystems\n";
 $sshconf .= "Subsystem\tsftp\t/usr/libexec/sftp-server\n";

And the slight adjustment I made for Terrapin:

--- /etc/inc/globals.inc.org	2023-02-02 08:47:26.000000000 -0800
+++ /etc/inc/globals.inc	2023-02-02 22:53:00.000000000 -0800
@@ -365,7 +365,6 @@
 
 global $ssh_keys;
 $ssh_keys = [
-	['type' => 'rsa', 'suffix' => 'rsa_'],
 	['type' => 'ed25519', 'suffix' => 'ed25519_'],
 ];
 
--- /etc/sshd.org	2023-02-02 08:47:26.000000000 -0800
+++ /etc/sshd	2023-02-02 22:53:00.000000000 -0800
@@ -70,7 +70,7 @@
 /* Include default configuration for pfSense */
 /* Taken from https://stribika.github.io/2015/01/04/secure-secure-shell.html */
 $sshconf = "# This file is automatically generated at startup\n";
-$sshconf .= "KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256\n";
+$sshconf .= "KexAlgorithms curve25519-sha256@libssh.org,curve25519-sha256\n";
 /* Run the server on another port if we have one defined */
 $sshconf .= "Port $sshport\n";
 /* Only allow protocol 2, because we say so */
@@ -116,7 +116,7 @@
 }
 $sshconf .= "X11Forwarding no\n";
-$sshconf .= "Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr\n";
+$sshconf .= "Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr\n";
-$sshconf .= "MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com\n";
+$sshconf .= "MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com\n";
 $sshconf .= "# override default of no subsystems\n";
 $sshconf .= "Subsystem\tsftp\t/usr/libexec/sftp-server\n";

dennypage

FWIW, ssh-audit was updated earlier this evening to include scanning for Terrapin.

jimp

@Skrillor said in Terrapin SSH Attack:

Hi there,

Fabian Bäumer (one of the authors from Terrapin) here. Just replying here to let you know that a workaround requires both, ChaCha20-Poly1305 and -etm MAC algorithms, to be disabled. If you only disable one of them (patch 1 and 2), the other one may still be exploitable if enabled.

Curious, the web site says AES-GCM is not affected, and CTR algorithms are not affected in real-world scenarios. By disabling only ChaCha, the only algorithms left active in the configuration on pfSense software are AES-GCM and CTR-based options. Perhaps the web site needs an update to reflect that? Or the patch could only leave AES-GCM enabled. If there is no real-world scenario where CTR+ETM is exploitable it's questionable to label it vulnerable, but that's open for debate I suppose.

dennypage

FWIW, In addition to pfSense, I've tested a few other Linux and Mac systems using both the Terrapin scanner and ssh-audit. On those systems, even without any other changes, both scanners indicate that disabling ChaCha alone (patch 1) is sufficient. I have not tested with just disabling -etm MACs (patch 2).

Of course, both scanners could be broken...

sandie

I fully agree with everything what Jim written, but… ;) OpenSSH 9.6 anytime soon in pfSense? (23.09.2?) :)
Thanks!

jimp

@sandie said in Terrapin SSH Attack:

I fully agree with everything what Jim written, but… ;) OpenSSH 9.6 anytime soon in pfSense? (23.09.2?) :)

I don't know that this is worth a point release all on its own especially given the timing. Given the high barrier to do anything meaningful, the workaround is sufficient for now unless new information comes up suggesting otherwise.

johnpoz

@jimp So will 9.6 be coming with the next normal release? I mean 9.5 was out a month before 23.09 dropped. I not sure why when 23.09 or even 23.09.1 came out why openssh wasn't updated to 9.5?

sandie

@johnpoz Newer <> Better often. I am going to apply Jim’s patch, but we will upgrade each and every system which offers OpenSSH 9.6 (hopefully not having too many of nodes).
I was just crosschecking what is the plan. I think this problem may be urgent only for people who need to use those ciphers, but we are going to stop using them.

mcury

I'm not in a hurry to apply these patches since I'm not exposing SSH to the internet.
SSH is only for my MGMT network.

So, I'm just waiting right now..

jimp

@johnpoz said in Terrapin SSH Attack:

@jimp So will 9.6 be coming with the next normal release? I mean 9.5 was out a month before 23.09 dropped. I not sure why when 23.09 or even 23.09.1 came out why openssh wasn't updated to 9.5?

We follow FreeBSD's lead here. We take whichever version is in base. At the moment that is 9.5p1 on dev snapshots. If they put 9.6 in base and we merge after that point, we'll pick it up.

the other

hey there,
first...thank you for your work, explanations, patch and work. :)
Then just a short feedback: although I do not have ssh open to the Internet, I used the nmap script to check..., of course, there it was: chacha and etm just as @johnpoz posted. And then it bugged me so much I installed the patch (first one of the two posted by @jimp) anyways. Rebooted, waited, checked ssh (which is still working) and got that mild feeling of relief (even though no ssh to Internet and only homenetwork with chance for MitM relatively small...but it feels better). So thanx for that one moment of easyness in pre-xmas-stress mode. :)

jimp

The patch to disable ChaCha and ETM is now available in System Patches Package v2.2.9 as a recommended patch. Read the linked thread before updating the package.

michmoor

@jimp
The patch works out nicely. Thanks to the prompt response.

monsen

I just noticed that this patch seems to "break" shh connectivity with Windows.

After applying the patch (and restarting the ssh deamon), when trying to SSH to the box from Windows, it now just reports

Corrupted MAC on input.
ssh_dispatch_run_fatal: Connection to 10.11.11.1 port 22: message authentication code incorrect

Tested disabling the patch, and everything was back working again. I made sure to test from multiple version of Windows and Windows server to confirm a general problem.

Doing a bit of ssh debugging, I noticed that Windows would try to use "umac-128@openssh.com" as the MAC algorithm, which is also is one of the ones listed as supported on the pfsense box after the patch. It also chose aes128-ctr as the Crypto algorithm. (OpenSSH_for_Windows_8.6p1, LibreSSL 3.4.3; among others)

It can be worked around on the Windows side by just excluding the umac-128@openssh.com algorithm either in the client config file or on the command line, or by forcing Windows to use AES-GCM.

I did some further testing, and while the issue isn't technically caused by the patch, it is still present even without the patch if you force the SSH client to choose the same algorithms it would have picked then, I still thought it worthwhile to report it here, since this patch is technically what will trigger the "bad" MAC algorithm.

This may (or may not) be a fault of Windows (or the OpenSSH client version compiled for Windows),

(Running Netgate 4100, 23.09.1-RELEASE)

STLJonny

@monsen

Simple fix that I've found, to fix my Windows to be able to ssh to my pfSense install (after applying the patch) is the following.

Add the following like to c:\users<user>.ssh/config

MACs hmac-sha2-512

This forced my ssh to use that MAC (message authentication code), of which pfSense is fine with.

JonathanLee

So is cha cha poly safe to use at this point? That is supposed to be the new advanced encryption algorithm. Disabling it kind of lets the bad guys win as we are degrading our systems by way of encryption algorithms. Is there a solution. Yes I am also aware that OpenVPN side doesn’t have support for it yet. The SMID assembly code is available on the processor I am using. Is this a software issue where not many programmers understand how to work with it? Bleeding edge software issues?

Just to confirm ChaCha is similar to a “Diffie-Hellman" algorithm? Based on the vulnerability explanation it acts just like one. Is it something new that had a security vulnerability? That exploit seems to have the ability to perform this on other algorithms as well. What makes sha better suited to this attack when they also do key exchanges?

aldomoro

This post is deleted!

stephenw10

@jimp said in Terrapin SSH Attack:

After applying the patch, reboot or restart the SSH daemon:

/usr/local/bin/php-cgi -f /etc/sshd

Like that. ^

DominikHoffmann

I take it, pfSense 24.03 has fixed this. Am I correct?