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
