upgring openssh since it's vulnerable

ageis

The latest community edition has a version of openssh that has security holes in it. am I correct in saying there isnt a way for me to fix this now?

https://www.cve.org/CVERecord?id=CVE-2024-6387

johnpoz

@ageis that looks like a specific redhat issue.. pfsense runs on freebsd.

I found this

https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server

Freebsd not screaming out to me.. Couple of things - it mentions.

(RCE) vulnerability in OpenSSH’s server (sshd) in glibc-based Linux systems.

Pfsense does not run on linux.

And then this about openbsd, which is freebsd brother.

OpenBSD systems are unaffected by this bug, as OpenBSD developed a secure mechanism in 2001 that prevents this vulnerability.

femtosize

@johnpoz https://www.freebsd.org/security/advisories/FreeBSD-SA-24:04.openssh.asc

johnpoz

@femtosize from 2024, listing old freebsd versions.. 2.8.1 runs FreeBSD 15.0-CURRENT

Just because the version of openssh says 9.7p1, and the cve shows 9.8p1 clear doesn't mean the version of openssh your running has not been patched.. Looks like to me this was patched in freebsd 14.1p2 - which pfsense 2.8.1 is running 15..

ageis

oh lesson learnt the pentest tool isnt bullet proof. thats very embrassing. nvm

johnpoz

@ageis many of those tools just look at big version numbers of applications and can give false positives all the time..

edit:
I think I saw a python script for specific test of this - you could prob run that if your really concerned.. But find it almost impossible to fathom this has not been patched in pfsense to be honest. Is your ssh exposed to the public internet? Or would you worried about attacks from your local network?

To be honest many of these sorts of exploits and issues can be mitigated with common sense security practices.. I personally wouldn't have ssh exposed to the public internet.. I vpn to pfsense when I need to remote admin it.

Locally the only things that should be able to even talk to the pfsense gui or ssh would be admin machines on your admin vlan, etc.

But you for sure did the right thing - check on it if concerned.. I would have to see if this was specifically addressed before with admin or developer chiming in. I don't recall this specific cve but from my quick look I would assume its been addressed quite some time ago.

edit2: here was the post from admin about it

https://forum.netgate.com/topic/189010/netgate-security-advisory-cve-2024-6387?_=1774639839498

here is another thread about it

https://forum.netgate.com/topic/188992/sshd-cve-2024-6387-vulnerability?_=1774639839506

ageis

@johnpoz I was just messing about.

I have already locked it to a particular ip.

Yeah i would agree but i embrassingly locked myself out of the vpn by changing it to use tcp instead of udp then forgot to update the firewall rule. lol. So I allow a back door. I use ssh to tunnel through to the admin interface.

I would stay away from the firewall if i ever get a job in IT support

johnpoz

@ageis said in upgring openssh since it's vulnerable:

I would stay away from the firewall if i ever get a job in IT support

ahahah ;)

stephenw10

Yup, this should have been fixed here: https://github.com/pfsense/FreeBSD-src/commit/2abea9df01655633aabbb9bf3204c90722001202
That's in 2.8.1.

SteveITS

@johnpoz said in upgring openssh since it's vulnerable:

Just because the version of openssh says 9.7p1, and the cve shows 9.8p1 clear doesn't mean the version of openssh your running has not been patched.

Side note, Red Hat and derivatives don’t change version numbers in patches. It was a bit annoying to talk to pen testers when we had more CentOS servers. “it’s fine trust me.” Or just turn off version display and let em guess. :)

johnpoz

@SteveITS said in upgring openssh since it's vulnerable:

Or just turn off version display and let em guess.

Hahah - yeah that is a common security thing anyway, not to display banners, etc.

I recall, this was back some time ago (long time ago) - they wanted for us to dump our sam db to give to them so they could scan for weak passwords and the like.. I told them if we are so insecure you get it yourself.. I will plug you into a user port.. You get the db ;)

told them - here look, this is our policy for what users need to set their passwords too, I am not just handing you the db on a silver platter ;)

Thought you were suppose to be testing our security - not telling me our users are using stupid passwords, which yeah they are users - they will do that ;)