Crying wolf over OpenSSH

In the security world, there is always tension between under and over-reporting on vulnerabilities. Not only between the "full" and "responsible" disclosure camps, but also for those trying to make sure that users are aware of the most recent attacks. Sometimes, that can lead to reports that eventually turn out to be incomplete, overstated, or flat out wrong. There is value even in incorrect reports, though; at a minimum they can raise the profile of the most vulnerable of services—reminding administrators to update and/or reconfigure the affected program—which may reduce the impact of the next exploit.

For many reasons, ssh vulnerabilities—or purported vulnerabilities—are treated differently than others. If this had been a report of yet another content management system cross-site scripting flaw or wireshark dissector bug, it would not have gotten much, if any, notice. But, ssh is one service that is turned on for nearly every server on the internet. Without ssh, many administrators couldn't access the server to handle important tasks—security updates for example.

In addition, many internet servers have just a few, trusted users, which may—unfortunately—make their administrators rather sanguine about patching for local privilege escalation flaws. That makes a way to subvert ssh and get that local access suddenly a much more dangerous flaw. In addition, many administrators allow root to log in remotely, so an ssh vulnerability might lead to root privileges without needing an additional privilege escalation flaw.

It is safe to say that exploitable ssh vulnerabilities are very high on the list of things that keep system administrators up at night. So that makes it rather easy to stir up a firestorm of publicity by reporting one. The Internet Storm Center (ISC) was one of the first to report on the rumored OpenSSH vulnerability (which we also passed along). The whole thing got started with a post to the full-disclosure mailing list that purported to show an ssh "zero-day" exploit compromising a server in New Zealand.

It wasn't very long before folks realized that it was likely the result of a "brute force" attack against a user password, but there was enough "chatter" of various sorts (see the updates on the ISC post) that it was difficult to be sure. In the end, we still aren't completely sure, but OpenSSH developer Damien Miller posted his belief that there was no ssh zero-day; ISC also posted a notice calling the vulnerability reports bogus. In the absence of any more information, those would seem to close the book on this vulnerability.

While it was a bit of a fire drill, it is likely that the reports led to some system administrators taking a look at their ssh installation to make sure it was up-to-date. They may also have tightened up their configuration in ways that might lessen the chances of a vulnerability affecting their systems. Disallowing root logins, requiring key-based instead of password-based logins, or restricting ssh access to certain IP addresses are all steps that administrators may have taken. Perhaps it was needless in this case, but a general tightening up of ssh configuration is likely to be helpful in fending off brute-force or other attacks down the road.