There’s a four-year-old bug in the Secure Shell implementation known as libssh that makes it trivial for just about anyone to gain unfettered administrative control of a vulnerable server. While the authentication-bypass flaw represents a major security hole that should be patched immediately, it wasn’t immediately clear what sites or devices were vulnerable since neither the widely used OpenSSH nor Github’s implementation of libssh was affected.
The vulnerability, which was introduced in libssh version 0.6 released in 2014 makes it possible to log in by presenting a server with a SSH2_MSG_USERAUTH_SUCCESS message rather than the SSH2_MSG_USERAUTH_REQUEST message the server was expecting, according to an advisory published Tuesday. Exploits are the hacking equivalent of a Jedi mind trick, in which an adversary uses the Force to influence or confuse weaker-minded opponents. The last time the world saw an authentication-bypass bug with such serious consequences and requiring so little effort was 11 months ago, when Apple’s macOS let people log in as admin without entering a password.
The effects of malicious exploits, assuming there were any during the four-plus years the bug was active, are hard to fathom. In a worst-case scenario, attackers would be able to use exploits to gain complete control over vulnerable servers. The attackers could then steal encryption keys and user data, install rootkits and erase logs that recorded the unauthorized access. Anyone who has used a vulnerable version of libssh in server mode should consider conducting a thorough audit of their network immediately after updating.
On the brighter side, there were no immediate signs of any big-name sites being bitten by the bug, which is indexed as CVE-2018-10933. While Github uses libssh, the site officials said on Twitter that “GitHub.com and GitHub Enterprise are unaffected by CVE-2018-10933 due to how we use the library.” In a follow-up tweet, GitHub security officials said they use a customized version of libssh that implements an authentication mechanism separate from the one provided by the library. Out of an abundance of caution, GitHub has installed a patch released with Tuesday’s advisory.
Another limitation: only vulnerable versions of libssh running in server mode are vulnerable, while the client mode is unaffected. Peter Winter-Smith, a researcher at security firm NCC who discovered the bug and privately reported it to libssh developers, told Ars the vulnerability is the result of libssh using the same machine state to authenticate clients and servers. Because exploits involve behavior that’s safe in the client but unsafe in the server context, only servers are affected.
How many sites?
A search on Shodan showed 6,351 sites using libssh, but knowing how meaningful the results are is challenging. For one thing, the search probably isn’t exhaustive. And for another, as is the case with GitHub, the use of libssh doesn’t automatically make a site vulnerable.
Rob Graham, who is CEO of the Errata Security firm, said the vulnerability “is a big deal to us but not necessarily a big deal to the readers. It’s fascinating that such a trusted component as SSH now becomes your downfall.”
Winter-Smith agreed. “I suspect this will end up being a nomination for most overhyped bug, since half the people on Twitter seem to worry that it affects OpenSSH and the other half (quite correctly!) worry that GitHub uses libssh, when in fact GitHub isn’t vulnerable,” he said. “Remove GitHub and my guess is you’ll be left with a small handful of random sftp servers or IoT devices and little else!”
The researcher provided additional details about the bug:
The issue is basically a bug in the libssh library, not to be confused with the similarly named libssh2 or OpenSSH projects (especially the latter) which results from the fact that the server uses the same state machine to authenticate clients and servers.
The message dispatching code that processes messages either in client mode or server mode (it’s the same function) doesn’t make sure that the message type received is suitable for the mode it’s running in. So, for example, the server will dispatch messages which are only intended by design for processing client side, even when running in server mode.
The SSH2_MSG_USERAUTH_SUCCESS message is used by the server to inform the client that they were authenticated successfully, it updates the internal libssh state machine to mark the client as being authenticated with the server. What I found was that if the exact same message is sent to the server it updates the state machine to tell the server the client is authenticated.
Technically: I would say that it’s surprising how fairly straightforward bugs with serious consequences can still lurk, and sometimes it pays to take a step back from fuzzing to try to understand how a protocol implementation works.
Again, anyone who runs a vulnerable version of libssh should patch immediately. And anyone who used the app to receive incoming connections from untrusted users should consider closely examining their servers for signs of compromise. At the same time, all indications at the moment are that the number of devices affected by this high-severity bug appear to be relatively small, a limitation that’s being lost on many people discussing this bug over social media.
This post will be updated as new information becomes available.
Be the first to comment