A serious, remotely exploitable security flaw in OpenSSH was announced June 26th, 2002. More than enough public...
information is now available to give an attacker the tools to create an exploit. What can you do to prevent this vulnerability being used to compromise your systems?
Upgrading OpenSSH is the best solution; 3.4 includes a fix for the problem (which is in the challenge response code). However, 3.4 was released June 26th, 2002, and no vendors (apart from OpenBSD) have issued updated OpenSSH packages that include version 3.4.
The best "workaround" is to install OpenSSH 3.3, which supports privilege separation. Many vendors started issuing OpenSSH 3.3 packages at the beginning of the week, thus saving administrators the problems inherent in downloading the source code and attempting to properly build and configure OpenSSH on their own, and then creating packages from it -- to say nothing of quality assurance or regression testing.
Privilege separation can be used to mitigate the effects of a successful attack on the sshd process. The major difference is that you will need to add a user and group called "sshd," and that for every SSH login there will be two sshd processes, one running as root and the other as the user currently logged in. The portion running as root is around 2,500 lines of code, making it much easier to audit; originally the entire package ran as root -- about 27,000 lines of code. Unfortunately upgrading has some unwanted side effects on a variety of platforms. Compression -- a critical feature for many people on slower links or with large amounts of data to transfer -- may no longer work. PAM's password aging is another issue. To enable privilege separation ensure the following line exists in sshd_config:
You will need to restart the SSH server. To ensure it is working login via SSH and issue a PS command, you should see something similar to:
root 12345 0.0 0.0 384 1108 ?? Is 11:14AM 0:00.09 sshd: seifried [priv] (sshd)
seifried 12346 0.0 0.0 380 1020 ?? S 11:14AM 0:00.20 sshd: seifried@ttyp0 (sshd)
for each ssh login.
This leads us to the next set of workarounds. You can disable the affected areas of code by disabling challenge response authentication and interactive keyboard logins. Simply edit your sshd_config and add or modify the following lines:
These lines may be present and set to "Yes" or the lines may not be present at all, if they are not present the code may still be enabled by default leaving you vulnerable. Restart the SSH server to make the changes take effect. A number of vendors, such as SuSE Linux, have stated they are not vulnerable to the flaw due to their default configuration; of course, anyone who uses these features and has enabled them is vulnerable.
This leaves people using challenge authentication in a difficult position as they must either upgrade OpenSSH or heavily restrict access to Port 22 to prevent an attacker from exploiting the problem.
Ultimately the best solution is to upgrade to 3.4. It contains a huge number of bug fixes that may also be exploitable; however, by upgrading to 3.3 or later and using privilege separation you will be able to avoid the worst of the problems. Even if an attacker is able to break in they will have a very difficult time breaking out of their chroot'ed non root user jail. If you are not able to upgrade, disabling challenge authentication should prevent exploitation. Due to the number of bugfixes in 3.4, however, it is highly likely that other exploitable problems are lurking in older versions.
About the author
Kurt Seifried is an Information Security Analyst with interests ranging from Microsoft and UNIX systems to network protocols and encryption (to name but a few). He has written a large number of articles (available online) and maintains many resources on his Website. He was formerly the senior analyst and main writer for SecurityPortal. Visit his site at http://seifried.org/security/.