LibSSH Vuln: You Don’t Need to See my Authentication

Another day, another CVE (Common Vulnerabilities and Exposures). Getting a CVE number assigned to a vulnerability is a stamp of authenticity that you have a real problem on your hands. CVE-2018-10933 is a worst case scenario for libssh.  With a single response, an attacker can completely bypass authentication, giving full access to a system.

Before you panic and yank the power cord on your server, know that libssh is not part of OpenSSH. Your Linux box almost certainly uses OpenSSH as the SSH daemon, and that daemon is not vulnerable to this particular problem. Libssh does show up in a few important places, the most notable is probably Github and their security team already announced their implementation was not vulnerable.

Libssh has released a new version that fixes the problem. Stick around for the details after the break.

The libssh project shares code between their client and server implementations, as one would expect. There are different callbacks to handle packet types as a new connection completes the handshake process. The SSH protocol defines several responses that are to be sent as an authentication request is handled. One of those messages is USERAUTH_SUCCESS, which the server sends to inform the client that authentication was successful, and the requested service is ready.

/** * @internal * * @brief Handles a SSH_USERAUTH_SUCCESS packet. * * It is also used to communicate the new to the upper levels. */
SSH_PACKET_CALLBACK(ssh_packet_userauth_success) { (void)packet; (void)type; (void)user; SSH_LOG(SSH_LOG_DEBUG, "Authentication successful"); SSH_LOG(SSH_LOG_TRACE, "Received SSH_USERAUTH_SUCCESS"); session->auth.state = SSH_AUTH_STATE_SUCCESS;

You may already begin to guess the vulnerability here. Libssh didn’t have a mechanism to determine if an incoming packet was allowed for the current state of the connection. An attacker could start a connection, the server would send the authentication challenge, and the attacker could reply with the USERAUTH_SUCCESS response. The problem is that this response is only meant to be sent by the server, not the client, and only after authentication is completed.

Because of the shared code, the server incorrectly jumps to the handler for this message type, and marks the authentication phase completed. At that point, the daemon sets up the SSH connection just as if the client had authenticated, rolling out the red carpet for the attacker.

The vulnerability was discovered by Peter Winter-Smith from NCC Group, who privately disclosed the issue to libssh. Updated releases of libssh were made available today, and the details of the problem were released at the same time. If you have libssh installed, and particularly if you’re using the server component, go install this important update.

It’s a nasty bug, but thankfully libssh doesn’t see widespread use as an SSH server, more often being used as an SSH client.