CVE-2023-48795 OpenSSH

[KBB]

Hi,
I have a Question related to CVE-2023-48795 (OpenSSH).
Does it affect the current Version of TrueNAS Core (Using 13.0-STABLE) and if this is the case can I use the Workaround from FreeBSD 12.4 to add following lines to /etc/ssh_config and /etc/sshd_config?

Code:

Ciphers -chacha20-poly1305@openssh.com
MACs -*etm@openssh.com

I know there are patches available for FreeBSD 13.2 and 14.

Thanks for your answeres.

 

[somethingweird]

instead of editing /etc/sshd_config. You might want to do this it the GUI?

Why - upgrades might wipe your changes.

 

[Davvo]

upgrades might wipe your changes.

Will.

 

[KBB]

Thanks for your replies.

I only considered this because it is described in the workaround in the FreeBSD Security mailing list.
Actually I have no problem if this is overwritten with the next update, then the security hole in OpenSSH should also be fixed, since there is an update. In addition, the config would then be set to the default value again.
But as a rule I don't make any changes to config files on the TrueNAS system. (Except of course through the GUI)

 

[Davvo]

On CORE 13.0-U6.1:

Code:

root@truenas[~]# ssh -V
OpenSSH_8.8p1, OpenSSL 1.1.1o-freebsd  3 May 2022

Apparently, every version before 9.6 is affected.

 

[KBB]

Yes, I read it too and wasn't sure if TrueNAS configures the ssh differently than the default.

If I understood the problem in OpenSSH and the solution correctly, then the attacker takes advantage of the fact that he can set the connection to a lower standard. The solution is to set the algorithm to a higher standard and disable the lower one.

I'm just not sure if I can use this with the FreeBSD 12.4 fix since the TrueNAS release train 13.0 is based on FreeBSD 13.1-RELEASE p9.

And since I haven't found anything on this topic for TrueNAS yet, I thought I'd start a thread about it.

 

[rvassar]

If you go to "Services" -> "SSH" click on the pencil "configure" option, then select "Advanced" you can add your proposed lines to the "Auxiliary Parameters", and restart the service. I just tested it, they do take effect. Attempting to connect with "-c chacha20-poly1305@openssh.com " results in:

Code:

Unable to negotiate with xxx.xxx.xxx.xxx port 22: no matching cipher found. Their offer: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,none

Then I realized I had aes128 and "none" enabled, so I went back and turned those off too.

 

[somethingweird]

Will.

Thanks for the heads up.

 

[Davvo]

Anyway, if you are not exposing your NAS to the internet you can just wait for the fix.

 

[KBB]

Yes that is the problem I use the SSH for exact that reason.
Right now I disabled the port forwarding.

I added following auxiliary parameters:

Code:

Ciphers -chacha20-poly1305@openssh.com
MACs -*etm@openssh.com

But still if I connect to the server via:

Code:

ssh ****** -vvv

I get following response:

Code:

debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1

So I think this didn't worked.

 

[rvassar]

Still working on my morning coffee, I'm not following... Why do you think it didn't work? Did you explicitly try to use the cipher ala:

Code:

ssh -vvv -c chacha20-poly1305@openssh.com nashost

Also, you have to stop and start the ssh service using the GUI slider.

 

[KBB]

Perhaps I have misunderstood.
Isn't that the message in the handshake that says which algorithms the server accepts?

Yes I restarted the service with the GUI.

Edit:
I tried to connect to the server with

Code:

ssh -vvv -c chacha20-poly1305@openssh.com nashost

and he responds that the server doesn't support it
I removed the auxiliary parameters and could connect to the server via

Code:

ssh -vvv -c chacha20-poly1305@openssh.com nashost

After each editing of the SSH service I restarted it with the slider.

In the documentation ssh_config the parameter should enable this cipher I am a little bit confused how the auxiliary parameter is working.
(Ah I over read that - would remove that cipher)

 

[rvassar]

Perhaps I have misunderstood.
Isn't that the message in the handshake that says which algorithms the server accepts?

Yes I restarted the service with the GUI.

Yes. I don't see chacha20-poly1305@openssh.com in the cipers lines, or *etm@openssh.com in the accepted MACs. But this particular CVE is kind of tricky. It requires a MITM, and the combination of both that cipher and that MAC. Take away either and the exploit fails. Hence I only tested by forcing the selection of chacha20-poly1305@openssh.com. It successfully connected before I made the change, and didn't afterwards, so I consider that proof of the desired effect.

 

[KBB]

Thanks for your help.
I will add again these two lines:

Code:

Ciphers -chacha20-poly1305@openssh.com
MACs -*etm@openssh.com

under Services->SSH->Configure->Advanced Options->Auxiliary Parameters.
Then save the config and restart the service though disabling and enabling again it with the slider.
To verify that it worked I would execute this command:

Code:

ssh -vvv -c chacha20-poly1305@openssh.com nashost

If they unable to negotiate the cipher this security vulnerability should be fixed.

Have a nice start in the day.

 

[Davvo]

Not using port 22 is also (marginally) helpful.

 

[rvassar]

If they unable to negotiate the cipher this security vulnerability should be fixed.

Have a nice start in the day.

Mitigated, not fixed. The flaw is still there in sshd, but the attacker can't exploit it because the specific flawed combination is disabled. I'm thankful my job shuts down for the next week. Our vulnerability scan will trip over the version alone, and demand patching even with the mitigation.

 

[wmo]

I can confirm that the bug CVE-2023-48795 exists in both current CORE and SCALE.

Our current plans are to fix this issue in the forthcoming TrueNAS CORE 13.1 and TrueNAS SCALE 24.02 releases.

In the meantime, please use the work-around suggested above:
GUI: Services->SSH->Configure->Advanced Options->Auxiliary Parameters

Ciphers -chacha20-poly1305@openssh.com
MACs -*etm@openssh.com

Click save, then stop and restart the ssh service.

Also, as suggested above, you can confirm that the workaround is in place in two ways:

ssh -c chacha20-poly1305@openssh.com TrueNAS_IP

You should expect output that looks like the following:

Unable to negotiate with TrueNAS_IP port 22: no matching cipher found. Their offer: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com

Alternatively, the authors of the original paper describing the attack have published a scanning tool written in Go. This tool is more generally useful if you have other systems that might be affected by this same bug:

GitHub - RUB-NDS/Terrapin-Scanner: This repository contains a simple vulnerability scanner for the Terrapin attack present in the paper "Terrapin Attack: Breaking SSH Channel Integrity By Sequence Number Manipulation".

This repository contains a simple vulnerability scanner for the Terrapin attack present in the paper "Terrapin Attack: Breaking SSH Channel Integrity By Sequence Number Manipulation". - R...

github.com

-Bill