openssh bugs - Jun 2012 - [Bug 2019] New: After a possible buffer overflow attack sshd does not accept connections any longer.

https://bugzilla.mindrot.org/show_bug.cgi?id=2019

             Bug #: 2019
           Summary: After a possible buffer overflow attack sshd does not
                    accept connections any longer.
    Classification: Unclassified
           Product: Portable OpenSSH
           Version: 5.4p1
          Platform: ix86
        OS/Version: HP-UX
            Status: NEW
          Severity: normal
          Priority: P2
         Component: sshd
        AssignedTo: unassigned-bugs at mindrot.org
        ReportedBy: Cliff.Brown at NCR.com


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

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2019

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au

--- Comment #1 from Darren Tucker <dtucker at zip.com.au> 2012-06-17
13:39:30 EST ---
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.

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.