Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Bug Security

Trivial Authentication Bypass In Libssh Leaves Servers Wide Open (arstechnica.com) 83

Ars Technica reports of "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." It's not clear how many sites or devices may be vulnerable since neither the widely used OpenSSH nor Github's implementation of libssh was affected. From the report: 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.

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.

This discussion has been archived. No new comments can be posted.

Trivial Authentication Bypass In Libssh Leaves Servers Wide Open

Comments Filter:
  • Between the Windows authentication bypass that just came and out (again) and this one, tomorrow is going to be a busy day at work.

  • by DaMattster ( 977781 ) on Wednesday October 17, 2018 @07:57PM (#57495708)
    Users of the OpenBSD versions (including portable) of SSH is not vulnerable to this issue. The OpenBSD OpenSSH uses its own version of libssh. You guys are safe.
    • by gweihir ( 88907 ) on Wednesday October 17, 2018 @08:34PM (#57495804)

      Just for those that do not know: Linux uses the OpenBSD ssh and hence is unaffected.

      Well, hopefully this niche-implementation is now dead...

      • The info I was looking for, thanks.
        • by gweihir ( 88907 )

          You are welcome. The alarmist headlines and missing information this gets reported with are an utter disgrace.

      • Yea what was even using that libssh? PalmOS?

      • Lightweight/embedded linux systems actually often use Dropbear ssh server. From a quick google, I get the impression that Dropbear doesn't use libssh, though.

        • by gweihir ( 88907 )

          Looking at the Dropbear ssh sources, it looks like it is self-contained, i.e. has its own implementation of the respective functionality. It may still be based on or inspired by the defective libssh. However, it does not list libssh in its copyright statement or acknowledgements and it probably would do so if it had taken code from there. It does list some code it took from putty and from OpenSSH.

          So I would say probably unaffected.

      • Just for those that do not know: Linux uses the OpenBSD ssh and hence is unaffected.

        Well, hopefully this niche-implementation is now dead...

        Mostly libssh still exists in Linux, but it seems the dependencies are: kio-sftp, kodi and libssh-dev. And the two applications both use it for client side which means they are not affected by this bug...

        That is the thing libssh is the neglected step child of SSH implementations, is it unused, and it is not surprising bugs are founded in it.

        • by gweihir ( 88907 )

          That is the thing libssh is the neglected step child of SSH implementations, is it unused, and it is not surprising bugs are founded in it.

          Exactly. Intensively used FOSS is usually excellent, but obscure, rarely-used one is often not. Sturgeon's law also applies to FOSS, just not equally.

    • by sjames ( 1099 )

      Actually, OpenSSH in general is safe.

  • Lots of software doesn't even try.

    Think on that when you're installing your smart devices.

    • by gweihir ( 88907 )

      The problem here is that this is not the mainstream libssh. It seems to be a rather exotic stand-alone project. The mainstream SSH is the OpenBSD SSH and it is _not_ affected. Anybody using an obscure alternate implementation of a security library basically gets what they deserve.

  • by WaffleMonster ( 969671 ) on Wednesday October 17, 2018 @08:03PM (#57495732)

    This has long been a pet peeve of mine in the design of these systems.

    People always feel the need to include messages indicating success or failure which is something I personally find to be dangerous and redundant.

    If it is ever possible for any peer to be at all confused about whether authentication was successful or not you are having a bad day and no amount of status indications are going to make the hole you are standing in any shallower.

  • by Zack ( 44 ) on Wednesday October 17, 2018 @08:07PM (#57495742) Journal

    This doesn't affect openssh servers or clients. Only *some* things using libssh *might* be vulnerable. A bit overhyped.

  • ... announces it to the world anyway.

  • by FeelGood314 ( 2516288 ) on Wednesday October 17, 2018 @09:40PM (#57495988)
    A finite state machine is a two dimensional array. You have your states and you have your events. Depending on your state you react to the events differently. If you write out your state machine on paper it should be obvious which {state, event} you have missed or implemented incorrectly. Yet I see so many state machines that:
    don't have a variable stating what state they are in
    have variables called previous state and current state
    have state names that are the action they intend to perform (usually you do something (transition) and then wait for something, hint your state name should probably be what you are waiting for)

    but the worst offenders are the ones that try and infer the state they are in based on only the event. javascript coders who try and make everything restful are the worst offenders here but it looks like the libssh authors are also guilty. How the fuck do you get your server into a client state? The only possible way is if you didn't actually define different states for client and server.
    • by johnw ( 3725 ) on Thursday October 18, 2018 @01:16AM (#57496532)

      As a partial answer to your question - my experience is that very many programmers simply can't get their heads around finite state machines. They want to write code which says, "Do X, then do Y, then do Z" and the furthest they are willing to get away from that is the odd "if" statement. The whole idea of having the code simply sit and react to events is too hard to comprehend.

      I've known a clearly implemented, well documented, state-machine driven bit of code enter maintenance, and then when I've come to look at it again a couple of years later it's had all sorts of horrible patches added to it. Asked for extra functionality, rather than adding an extra row (state) to the table, the maintainers added lots of "if"s and flags to the action routines, as if actively trying to turn it back into spaghetti code.

    • Yet I see so many state machines that:

      don't have a variable stating what state they are in

      have variables called previous state and current state

      I'm curious here - assuming those two points of yours are both bad things, they seem contradictory - wouldn't the variable called "current state" be "a variable stating what state they are in"?

    • An even bigger problem here is that what's being done doesn't need a state machine. Nor does TLS, which is also described in the spec as a state machine, and there were a whole pile of vulns discovered a year or two back where you could flip different implementation's state machines into unexpected (and illegal) states.

      If you look at what both TLS and SSH do, it's basically, client says A, server says B, client says C, server says D, client says E, server says F, and then they're done. It's a fixed series

  • by Anonymous Coward

    A "feature" was the ability to change your password while logging in. To do this, you'd type "password/new/new". However, the code for setting the new password had a bug where if it was null, it didn't check whether "password" was correct! So, by logging in with "//" as the password, one got in, AND reset the password to the empty string!

Keep up the good work! But please don't ask me to help.

Working...