Bugtraq mailing list archives
severe error in SSH session key recovery patch
From: Matt Power <mhpower () BOS BINDVIEW COM>
Date: Fri, 9 Feb 2001 14:38:02 -0500
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 () bos bindview com
Current thread:
- severe error in SSH session key recovery patch Matt Power (Feb 10)
- Re: severe error in SSH session key recovery patch Andrew Brown (Feb 12)
- Re: severe error in SSH session key recovery patch Kari Hurtta (Feb 12)
- Re: severe error in SSH session key recovery patch Robert Varga (Feb 12)
- Re: severe error in SSH session key recovery patch Tatu Ylonen (Feb 13)
- Re: severe error in SSH session key recovery patch Andrew Brown (Feb 12)