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
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
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
to post comments)