search

vmware / photon

Minimal Linux container host
https://vmware.github.io/photon
Other
3.06k stars 697 forks source link

sshd.socket vulnerable to DoS #1480

Open t3easy opened 1 year ago

t3easy commented 1 year ago

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.

journalctl_sshd

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 commented 1 year ago

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

dcasota commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

what is the status of sshd.socket ?

t3easy commented 1 year ago

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

t3easy commented 1 year ago

@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. image

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

t3easy commented 1 year ago

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

t3easy commented 1 year ago

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

dcasota commented 1 year ago

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

(edited)

@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 commented 1 year ago

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

dcasota commented 1 year ago

@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 commented 1 year ago

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

t3easy commented 1 year ago

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