CVE-2023-51384 and CVE-2023-51384

saidin

Hi Community

I hope you can help me out with these 2 queries.

Is there any official documentation that shows if the below vulnerabilities affect the CE 2.7.2 ?

CVE-2023-51384
CVE-2023-51385

I could not find any information in the advisories web page.

https://docs.netgate.com/advisories/index.html

Assuming that any/both affect the version 2.7.2, does anyone know what version of openssh is going to be used on the next release? I guess it would be 2.8.0.

Currently the version of open ssh seems to be 9.4 and the openssh that fixes both vulnerabilities is > 9.6.

saidlopez@Saids-MBP ~ % ssh -vv   mx045322@159.x.x.x  -p 2222 -L8443:localhost:8443 
OpenSSH_9.6p1, LibreSSL 3.3.6

debug1: Local version string SSH-2.0-OpenSSH_9.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.4

Thank you in advance.
Regards
Said

stephenw10

Currently internal builds are:

[2.8.0-DEVELOPMENT][admin@cedev.stevew.lan]/root: ssh -V
OpenSSH_9.7p1, OpenSSL 3.0.13 30 Jan 2024

skogs

EDIT - ffs... I read the second line that said 9.6 and was then wondering why concerned? ... seems I thought hard and THEN saw the 9.4.
Apologies.

Both advisories were published on December 18th. The same date that the 9.6/9.6p1 was released. The release notes for openssh 9.6 specifically call out change since 9.5 was fixing up both the PKCS#11 private keys and usernames with strange stuff.
https://www.openssh.com/releasenotes.html
The advisory was published after it was fixed internally and published. You already have the fix.

Generally speaking, CVE-2023-51385 isn't really much of an issue. It takes a special kind of weirdo to have valid usernames or host names that use pipes, $, and backticks or parenthesis. Naturally nobody really does this. This requires such a specific user/host combination to be virtually unusable on the red team side. Sure, an attacker could make an account, then use it to inject commands...but if they're already making users why bother?

Even CVE-2023-51384 ... my experience might not reflect your reality, but our work tokens used to have multiple private keys on them but haven't for several years. One card. One purpose.

stephenw10

Yup, I agree with that, neither are a huge concern in pfSense. IMO.

skogs

Also I checked my plus. It is appropriate version on plus.
And no, this isn't holding out stuff for paying customers and shafting the community...cert token auth is generally an organization that should be paying the license fee anyway. Home users just plain don't do that very often... nor is it exploitable reasonably. Same with the system names thing. This is a rare thing...even more rare in non professional roles.