There are so many vulnerabilities disclosed each day that it’s impossible to keep track of all of them and difficult to even take note of all the critical ones. But occasionally, a bug comes along that is so weird it demands attention.
The recent libSSH vulnerability is that kind of bug.
It’s the kind of bug that attackers dream about and developers stay awake at night worrying about. The vulnerability is in the server-side code of the libSSH library, which is used in numerous applications to implement the SSH protocol. The problem lies in the way that the server code handles specific messages from the client, namely messages that tell the server that the client has authenticated successfully. The libSSH library is implemented in a slew of applications and many enterprises use it internally.
“Careful reading of code for the affected libSSH library indicated that it was possible to bypass authentication by presenting to the server an SSH2_MSG_USERAUTH_SUCCESS message in place of the SSH2_MSG_USERAUTH_REQUEST message which the server would expect to initiate authentication. The SSH2_MSG_USERAUTH_SUCCESS handler is intended only for communication from the server to the client,” an advisory by Peter Winter-Smith of NCC Group, who discovered the bug, says.
In other words, an attacker can connect to any vulnerable server, without authentication, just by sending one message to the server. That is not expected behavior. The vulnerability is the result of the way that the libSSH library handles the shared state between the server and the client. Winter-Smith said that while not every server that supports libSSH is vulnerable to the authentication bypass attack on this bug, there are probably other ways to exploit it.
“Not all libSSH servers will necessarily be vulnerable to the authentication bypass; since the authentication bypass sets the internal libSSH state machine to authenticated without ever giving any registered authentication callbacks an opportunity to execute, servers developed using libSSH which maintain additional custom session state may fail to function correctly if a user is authenticated without this state being created,” the advisory says.
“It is important to note that the authentication bypass exploit detailed above is the most obvious route to exploitation for the overarching issue – the libSSH server state machine is vulnerable to being updated by messages intended only for handling on the client side. Even servers which are not vulnerable to the authentication bypass will may still be vulnerable to other unexpected state manipulation issues, so it is imperative that all services built on top of libSSH are updated even if not demonstrated vulnerable to the authentication bypass.”
The maintainers of libSSH library released patched versions of the library, versions 0.7.6 and 0.8.4, and apps that were built with a vulnerable version of the library in server mode should be rebuilt with the patched version, Winter-Smith said.