Bug 2019

Summary:	After a possible buffer overflow attack sshd does not accept connections any longer.
Product:	Portable OpenSSH	Reporter:	Clifford Brown <Cliff.Brown>
Component:	sshd	Assignee:	Assigned to nobody <unassigned-bugs>
Status:	CLOSED WORKSFORME
Severity:	normal	CC:	djm, dtucker
Priority:	P2
Version:	5.4p1
Hardware:	ix86
OS:	HP-UX

Description Clifford Brown 2012-06-17 07:56:49 AEST

Hello,
We have a number of servers all around the world that are running sshd as the only means to remotely log into the system. Our network security department has a server 10.6.2.50 using a security program called Regina Scan. Retina Scan periodically interrogates the systems attempting different known attack's to see if any of the systems fail the attack. We are then notified when this happens usually requiring an upgrade.

We are running into a problem where if the test is a Buffer overflow attack then sshd resists the attack but then will not accept connections after the attack. Since local personnel do not have the root password so this requires powering the server off/on. This does not always happen. Sometimes sshd recovers and continues on normally.

Below are examples of the log entries we are seeing. I don't know if this is a bug or just a configuration problem. I have not been able to find any solution in the readme file for 6.0 or on the web. So I am escalating this to the group to see if I can get some direction.

15:03:03: sshd: Did not receive identification string from <IP address>
15:04:29: sshd: Bad protocol version identification ' ' from <IP Address> 15:04:29: error: reexec socketpair: Interrupted system call
15:04:29: error: ssh_msg_recv: read: header
15:04:29: mountd: mount (version 3) attempt failed for /home2/refpos request from <IP Address>

Subsequent messages in the log

15:06:54: sshd: error: ssh_msg_recv: read: header
15:06:54: fatal: recv_rexec_state: ssh_msg_recv failed

Comment 1 Darren Tucker 2012-06-17 13:39:30 AEST

There's not a lot of information to go on here.  My guess is that the main sshd is running out of file descriptors but that's only a guess.

Can you reproduce the problem with the current version of OpenSSH?  What exactly does this "Regina Scan" thing send to sshd?  Does it make lots of separate connections in parallel or in series?  What version of HPUX are you using and does it have a native /dev/random device?  If not, are you using prngd?  What's the ulimit setting for number of files (ulimit -n)?

A couple of possible workarounds:
1) increase the number of file descriptors in whichever script starts sshd (ie put "ulimit -n 4096" or some suitably large number somewhere before sshd is invoked).
2) Reduce MaxStartups to, say, half of what it's currently set to.  This will mean that you'll have less unauthenticated connections at any time which should reduce the peak number of descriptors in use.
3) run sshd with the (undocumented) "-r" flag, which will turn off the reexec behaviour, which will also reduce the number of descriptors in use.  Note that this will also disable the protection of any run-time randomization (ASLR, stack cookies and such) so if your OS actually provides any of these things you'll actually be *more* at risk.

Comment 2 Damien Miller 2013-02-08 11:19:45 AEDT

6 months with no followup = no bug

Comment 3 Damien Miller 2016-08-02 10:42:22 AEST

Close all resolved bugs after 7.3p1 release