Slashdot Mirror


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

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.

2 of 83 comments (clear)

  1. Why can't people write finite state machines by FeelGood314 · · Score: 4, Interesting

    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.

    1. Re:Why can't people write finite state machines by johnw · · Score: 3, Interesting

      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.