CVE-2024-7589

sokeada

Hope system patch will release soon, I really appreciate your work.

Gertjan

The good news is :

According to what is said here : https://thehackernews.com/2024/08/freebsd-releases-urgent-patch-for-high.html

In cases where sshd(8) cannot be updated, the race condition issue can be resolved by setting LoginGraceTime to 0 in /etc/ssh/sshd_config and restarting sshd(8). While this change makes the daemon vulnerable to a denial-of-service, it safeguards it against remote code execution.

And guess what : check your pfSense /etc/ssh/sshd_config and see that :

LoginGraceTime 0s

Keep in mind that on pfSense sshguard is still guarding the SSH access, so any denial-of-service attempst will quickly end up hitting the firewall.
SSH is normally only accessible on a trusted LAN (LAN or some OPTx interface) and that nobody (pfSense) has SSH open on the WAN anyway.
So, me back to bed for the time being.

sokeada

@Gertjan thanks for the tip and quick respond, let me find out and follow your suggestion.

sokeada

@Gertjan said in CVE-2024-7589:

LoginGraceTime 0s

Im my pfSense 2.7.2 default sshd_config is set LoginGraceTime to 0s already so no need to do anything, right?

Gertjan

@sokeada

Right.

Just double check that only 'you' can access the SSH port, by allowing it using firewall rules on the interfaces you don't SSH to be accessed, if you have multiple LANs. And/or add a firewall on your trusted LAN so only your device (your IP - using port 22 TCP) can use SSH.
Or even : shut down SSH when you don't need it, as you can enable it with a click in the GUI.

Btw : be ware : I'm not a security guy. I'm just applying common sense.

sokeada

@Gertjan your instruction is make sense to me. I already applied that too except turn on/off ssh via GUI when needed. That's another tip. Thanks you so much.