Terrapin SSH Attack

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?

stephenw10

Yes it was patched in openssh 9.6.

[24.03-RELEASE][admin@4200.stevew.lan]/root: ssh -V
OpenSSH_9.6p1, OpenSSL 3.0.13 24 Oct 2023

lifeboy

@stephenw10 I see that CE 2.7.2 doesn't have openssh 9.6 yet. Does one manually have to upgrade openssh?

stephenw10

There is a patch in the system patches package to disable the affected ciphers. Apply it.

willowen100

Hi

I know this is an old post, I'd like to add that I too am having problems connecting from a Windows client PC using OpenSSH.

With the below patch applied
Workaround for Terrapin SSH Attack (After applying the patch, reboot or restart the SSH daemon, FreeBSD-SA-23:19.openssh, Terrapin Attack)

I get an error connecting

PS C:\Users\Will> ssh admin@192.168.5.1
Corrupted MAC on input.
ssh_dispatch_run_fatal: Connection to 192.168.5.1 port 22: message authentication code incorrect

After listing the MAC algorithms with

PS C:\Users\Will> ssh -Q mac
hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512
hmac-md5
hmac-md5-96
umac-64@openssh.com
umac-128@openssh.com
hmac-sha1-etm@openssh.com
hmac-sha1-96-etm@openssh.com
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com
hmac-md5-etm@openssh.com
hmac-md5-96-etm@openssh.com
umac-64-etm@openssh.com
umac-128-etm@openssh.com

If I try connecting with the first MAC algorithm I get a prompt to try different ones

PS C:\Users\Will> ssh admin@192.168.5.1 -m hmac-sha1
Unable to negotiate with 192.168.5.1 port 22: no matching MAC found. Their offer: hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

The only way to connect to pfSense via SSH is with

ssh admin@192.168.5.1 -m hmac-sha2-512

Once in pfSense I'm able to get the OpenSSH version

[2.7.2-RELEASE][admin@pfSense.lan]/root: ssh -V
OpenSSH_9.4p1, OpenSSL 3.0.12 24 Oct 2023

Some more information can be found here at the link below
https://serverfault.com/questions/994646/ssh-on-windows-corrupted-mac-on-input

Is there any fix with this on the pfSense CE edition?

STLJonny

@willowen100 See my reply, above in this thread, for a fix from the windows side.

willowen100

@STLJonny That works perfectly!

STLJonny

@willowen100 It basically forces your ssh (on the Windows side) to utilize that encryption algorithm. You'll need to do that on any machine you ssh from.

I'd have rather found a more elegant workaround (preferably on the pfSense side, so the mod only has to be done in one location), but this works in a pinch.