severe error in SSH session key recovery patch

[Matt Power]

http://www.core-sdi.com/advisories/ssh1_sessionkey_recovery.htm
includes the line of code:

  kill(SIGALRM, getppid());

This is contained within what is listed as an "unsupported and
untested patch" developed by SSH.com.

The problem is that the arguments to "kill" are in the wrong order. In
other words, to obtain the effect that was apparently intended, the
line of code should have been

  kill(getppid(), SIGALRM);

One effect is that the patch does not, in any way, help reduce the
risks associated with the session key recovery vulnerability, since
the parent process will not receive an ALRM signal and thus will not
regenerate a server key. The other possible effect is that there might
be a process whose pid is equal to the numerical value of SIGALRM, and
the value of getppid() might be a signal number that, if sent, would
have an adverse effect on that process and consequently an adverse
effect on system stability. (The call to "kill" is fine in the rare
case where SIGALRM and getppid() happen to be numerically equal.)

(This posting is intended to point out the error in the "kill" line of
that patch; it is not intended to provide a recommendation that the
patch be used if the "kill" line is corrected.)

To determine whether the corrected patch seems appropriate for one's
intended application, here are a few other factors to consider:

  -- if sshd is run from tcpserver (see
     http://cr.yp.to/ucspi-tcp/tcpserver.html) using a command line
     such as "tcpserver 0 ssh /usr/local/sbin/sshd -i", the
     "kill(getppid(), SIGALRM);" will cause the tcpserver process to
     terminate. Unless another process exists that will automatically
     restart that tcpserver process, access to the system via ssh will
     be no longer available. There may be a version of inetd or an
     inetd derivative that will also terminate upon receiving an ALRM
     signal. However, it is commonly the case that an inetd process
     will not terminate if it receives an ALRM signal.

     It happens to be the case that the patch involving
     "kill(getppid(), SIGALRM);" is not needed if sshd is run from
     either tcpserver or inetd. Still, some organizations may be
     deploying a version of sshd with this patch onto systems where
     tcpserver is used, especially if they are using an sshd package
     that was put together without this tcpserver issue in mind.

     It is not a bug in tcpserver that the process terminates when
     it receives an ALRM signal. Any "normal" program started by
     tcpserver will not be sending an ALRM signal to getppid(), so
     one shouldn't expect the design of tcpserver to anticipate that.

     Running an sshd supporting SSH protocol 1.5 from inetd/tcpserver
     rather than standalone is a tradeoff between DoS concerns and
     session-key-recovery concerns. The right decision will not be
     the same in all environments.

  -- With the patch, the lifespan of the server key still does not go
     below one minute. As mentioned in CORE SDI's advisory, the number
     of server connections necessary to carry out the attack is
     normally very large but "the number of connections given is for
     the average case and specifics cases will fall below the
     average". This suggests that is not entirely out of the question
     for the attack to succeed within one minute. If that risk is not
     appropriate in one's environment, then other measures (which may
     include inetd/tcpserver but may also include desupporting use of
     SSH protocol 1.5) are needed.

Matt Power
BindView Corporation, RAZOR Team
mhpower at bos.bindview.com