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) {

  SSH_LOG(SSH_LOG_DEBUG, "Authentication successful");

  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.

19 thoughts on “LibSSH Vuln: You Don’t Need to See my Authentication

    1. Nope, dropbear has it’s own implementation,based on a different library.

      I think this library is used less then you would expect from the name. It’s named libssh-4 in debian, and only a few other packages depend on it:

      daid@black:~$ apt-cache rdepends libssh-4
      Reverse Depends:

      1. Sorry bro but software development is engineering by definition.

        engineering noun
        en·gi·neer·ing | \ˌen-jə-ˈnir-iŋ \
        Definition of engineering
        1 : the activities or function of an engineer
        2a : the application of science and mathematics by which the properties of matter and the sources of energy in nature are made useful to people
        b : the design and manufacture of complex products
        // software engineering

        3 : calculated manipulation or direction (as of behavior)
        // social engineering

          1. Did you build the OS you are using from the blueprints (source) ou just installed it? the compiling (building) of the source is reproducible. Using unqualified, untrained “programmers” will however result in a unstable build, just as using an unqualified, untrained “architect/electrical engineer/etc” will result in shoddy work

        1. I hear you!!, but when MS Word messes up your formatting due to a bug, no one is accountable. An anyone that’s taught themselves JavaScript can call themselves a “software engineer”. On the other hand, real engineers need to get some kind of accreditation to be able to sign off their work, and are liable when things break because of their negligence. Many “software engineers” would be bankrupted by lawsuit if they were actually engineers :)

          1. If you ever developed code that went into a medical device you would not be saying this. The level of scrutiny by the FDA for a Level III (life-critical) medical device would make a classic engineer quit in frustration. Yes consumer products do not have the level of accountability that a civil engineer does, but a biomedical software engineer has just as much if not more accountability, so your blanket statement is not correct.

            I am not a biomedical software engineer, but have worked closely with them as an FAE for a company whose component was integrated into a Class I device. The level of headaches they needed to endure for this lowest level of approval was excruciating. I am glad I burned out of the biomed engineering program while in college, I wouldn’t wish dealing with the byzantine regulation in that field on my worst enemy.

        2. I’m a software developer myself, so I could easily call myself an “engineer”. But I don’t because I can’t get sued if my product doesn’t work properly. Don’t get me wrong – I have the greatest respect for actual, engineers, but software developers aren’t them.

          My friend whose a carpenter, also doesn’t call himself an engineer, even though his design work is reproducible.

          1. It just depends at what level you’re engineering, if your friend who’s a carpenter produced a structure which harmed a person or caused a significant loss of revenue I would very much expect him to be sued.
            In places where software engineering isn’t chartered the same effect is usually produced by contract between engineer and company, and company and customer.

      1. git was not acquired by Microsoft, but the company GitHub was. GitHub is not very distributed, you can have clones of your code repository and wiki (which is also stored in git), but everything else it does is pretty centralized.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.