Flaw in Libssh Grants Admin Control to Servers

Written by

Security researcher Peter Winter-Smith discovered a four-year-old authentication bypass vulnerability in the server code of libssh versions 0.6 and above. According to Winter-Smith’s tweet, “The root cause is that the libSSH server and client share a state machine, so packets designed only to be processed by and update the client state can update the server state.”

In the security advisory for CVE-2018-10933, Winter-Smith summarized, “There is a vulnerability within the server code which can enable a client to bypass the authentication process and set the internal state machine maintained by the library to authenticated, enabling the (otherwise prohibited) creation of channels.”

An attacker could authenticate without credentials by presenting the server with an SSH2_MSG_USERAUTH_SUCCESS message, rather than the expected SSH2_MSG_USERAUTH_REQUEST message, which initiates authentication, though only those versions running in server mode are vulnerable.

There is reportedly no workaround for the issue, and according to the advisory, patches have been released by Anderson Toshiyuki Sasaki of Red Hat and the libssh team that address the issue for libssh version 0.8.4 and libssh 0.7.6.

Winter-Smith told Ars Technica that the vulnerability is the result of libssh using the same machine state to authenticate clients and servers, yet only servers are affected because behaviors in the exploit are actually safe in the client side. No high-profile sites have reportedly been affected by the vulnerability. Though Github uses libssh, the company stated on Twitter that it is unaffected by the vulnerability due to how it uses the library.

When pressed for clarification on how GitHub enterprise remained unaffected despite its use of the libssh in SSH server mode, GitHub tweeted, “We use a custom version of libssh; SSH2_MSG_USERAUTH_SUCCESS with libssh server is not relied upon for pubkey-based auth, which is what we use the library for.  Patches have been applied out of an abundance of caution, but GHE was never vulnerable to CVE-2018-10933."

What’s hot on Infosecurity Magazine?