Terrapin SSH Attack

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.