sshd.socket vulnerable to DoS

[t3easy]

Describe the bug

After some time, the sshd service stops.
It's just 2 seconds after our monitoring checks for ssh port 22.
journalctl shows

Received signal 15; terminating.

The VM is a fresh install from the x86_64 ova.

Reproduction steps

1. Run Photon OS 5.0 GA with sshd
2. Run a monitoring that tests port 22

Expected behavior

sshd don't terminate

Additional context

No response

[vbrahmajosyula1]

Can you please describe what the monitoring does? For example does it open N connections at once?

[dcasota]

Is there a process with systemctl restart sshd somewhere?
In addition, in RC5.0 ova (#1417 3.2) by default there was PermitRootLogin yes configured in /etc/sshd/sshd_config.

[t3easy]

Can you please describe what the monitoring does? For example does it open N connections at once?

@vbrahmajosyula1
The monitoring uses the common check_ssh tool from monitoring plugin:
https://www.monitoring-plugins.org/doc/man/check_ssh.html
https://github.com/monitoring-plugins/monitoring-plugins/blob/master/plugins/check_ssh.c

Is there a process with systemctl restart sshd somewhere? In addition, in RC5.0 ova (#1417 3.2) by default there was PermitRootLogin yes configured in /etc/sshd/sshd_config.

@dcasota
If I start sshd it runs for some time.
PermitRootLogin yes is still set in 5.0 GA, but it was also in 3.0 and 4.0. Why should this be a problem regarding the described issue?

Just seen, there are updates for openssh-server since some minutes to 9.3p1-1.ph5. I'll try to update and check if the problem still occurs.

[ssahani]

when you try to login does the ssh connecting fails ? the .socket units forks a new daemon when it receives a new connection and closes when none is active .

[dcasota]

CVE-2023-25136 has been fixed in openssh 9.2p1.
edited:
The openssh 9.1 version included in the Ph 5.0 GA bits unfortunately had several issues.
Accordingly to https://www.openssh.com/releasenotes.html, openssh 9.2p1 security fixes: fix a pre-authentication double-free memory fault introduced in OpenSSH 9.1.
The cve-bin-tool scanner refers to CVE-2023-28531, CVE-2008-3844, CVE-2007-2768 with severity critical,high,medium when scanning openssh-server-9.1p1-8.ph5.x86_64.rpm, see scan output.

[t3easy]

when you try to login does the ssh connecting fails ? the .socket units forks a new daemon when it receives a new connection and closes when none is active .

Yes, I can't connect, I had to open the vm console. At this time, the sshd service was dead.

[ssahani]

what is the status of sshd.socket ?

[t3easy]

@ssahani I'll check the next time, the problem occurs.
What I can tell is that such connections will not be cleaned up properly:

[t3easy]

@ssahani All of our Photon OS 4 VMs started with the same problem after the last updates.

ssh photon-vm.xyz
kex_exchange_identification: read: Connection reset by peer

systemctl status sshd.socket shows a lot of triggered sub services.

In this case, they are also generated by docker context over ssh.

[t3easy]

Found this info: https://wiki.archlinux.org/title/OpenSSH#Daemon_management

[t3easy]

https://bugzilla.redhat.com/show_bug.cgi?id=2025716

[dcasota]

@t3easy could you check the behavior with a modified /etc/ssh/sshd_config ?

(edited)

• MACs hmac-sha2-512,hmac-sha2-256
• LoginGraceTime 1m
• ClientAliveInterval 300 + ClientAliveCountMax 0
• PermitRootLogin no
• PermitUserEnvironment no

@ssahani I'm not sure about the ciphers, kex and secure hash algorithms supported in Photon OS 3,4,5. Could you double check? In addition, I'm not sure how to reconfigure openssh to not use sshd.socket at all.

[t3easy]

@dcasota If I understand the settings right, they make sure a ssh session keeps established, they don't close old one.

[dcasota]

@t3easy The settings suggested is a mix to ensure the service is available for needed access.
Such an issue may contain multiple aspects e.g. subcomponent version bugs, hardening level, dependencies and maximum limits. When running a pentesting ssh it is good to know as result the default hardening level and what are the vulnerabilities of the system. If you need connect simultaneously from multiple ssh servers, it is good to know as result the maximum limits, but also tuning options.

[t3easy]

As I have not had the leisure to test it, I disabled sshd.socket and go for sshd.service.

[t3easy]

https://bugs.archlinux.org/task/62248