The flames occurred because de Raadt published his advice but didn't provide any details of the actual vulnerability. A comment made on OpenBSD.org by Michael Richards -- not a flame, just a comment -- suggested that there was an obscure backdoor in OpenSSH 3.3.1 that makes it dangerous to blindly follow de Raadt's upgrade and workaround advice. Geek.com reported that Allen Cox, described in that story as Linus Torvald's right-hand man, suggested that de Raadt might be trying to force a Trojan on everyone by urging the immediate upgrade to OpenSSH 3.3 without any detailed explanation of the threat. Risk level: Serious
A lot of systems use OpenSSH; any vulnerability in this open source code can be very dangerous. The problem -- which can be exploited, according to the bug report released by OpenSSH.com -- is that when ChallengeResponseAuthentication is enabled in sshd_config, it can result "in an integer overflow and privilege escalation." Internet Security Systems has also released an advisory on this issue; in it they comment on the seriousness of this threat by saying, "It is possible for a remote attacker to send a specially-crafted reply that triggers an overflow. This can result in a remote denial of service attack on the OpenSSH daemon or a complete remote compromise. The OpenSSH daemon runs with superuser privilege, so remote attackers can gain superuser access by exploiting this vulnerability." Applicability
OpenSSH is shipped with most versions of Linux and many flavors of UNIX. All versions of OpenSSH from 2.9.9 through 3.3 are affected by this other vulnerability. Internet Security Systems also recommend that users of earlier versions upgrade to version 3.4, even though 2.9 and earlier releases aren't vulnerable to this particular problem. The fix: Upgrade or apply workaround
Just as the controversy over this workaround was starting to heat up, OpenSSH.com was able to release a new version (3.4), which apparently addresses both the complaint made by Richards and fixes the problems mentioned by de Raadt. OpenSSH also published the following workaround that you can use until you have time to install the new version: "Disable ChallengeResponseAuthentication in sshd_config or enable UsePrivilegeSeparation in sshd_config." In essence, this workaround splits OpenSSH into two separate processes: One manages decision-making and the other connects to the network, thus insulating the network from any damage in the event a hacker exploits the vulnerability. This may reduce the usability of some features contained in OpenSSH. Final comments
At first glance, de Raadt did everything right; he posted just enough information for managers to protect their systems without any details that would allow vandals to exploit the vulnerability before patches or upgrades could be posted. It seems to me that you couldn't ask much more of a developer. His stated reason for urging an upgrade to version 3.3 makes perfect sense since he reported that the workaround wouldn't be 100 percent effective on earlier versions. On the other hand, it turned out that there apparently was an additional vulnerability in version 3.3 which would make systems vulnerable if managers did perform the upgrade he initially suggested. I guess it all boils down to whether or not you trust de Raadt's motives. As lead developer, he can probably plant virtually any code in OpenSSH that he wants to, so if you don't trust him and his motives in this instance, how can you use any version of OpenSSH? In any case, if you don't trust OpenSSH or de Raadt and take him at his word, you should probably stick to using Telnet. If you do rely on secure shell for remote logins, you should upgrade your systems to OpenSSH 3.4 as soon as possible.
Have your say instantly in the Tech Update forum.
Find out what's where in the new Tech Update with our Guided Tour.
Let the editors know what you think in the Mailroom.
