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.

Comments

OpenBSD OpenSSH not vulnerable

[DaMattster]

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.

Re:OpenBSD OpenSSH not vulnerable

[gweihir]

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

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

Re:OpenBSD OpenSSH not vulnerable

[gweihir]

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

Re: OpenBSD OpenSSH not vulnerable

[Excelcia]

Nice. And do you trust the dev that wrote a library which accepted client assurance that it authenticated properly for 4 years to be professionally written in every other way?

That's not an iconic example of sophistry at all.

Ok, first of all, libssh didn't make any representations about its software properly authenticating. No one makes those assurances, at least, not in any realistic sense. The only assurances you'll get for software is by forking out (usually large amounts) of money for someone who will say the words, in which case all it really means is they have no better idea than any other programmer that there aren't door-crasher bugs, they are just willing to cover the liability suits out of moneys earned charging people exorbitant fees to say there aren't any bugs.

There are never assurances software (or, as we learned recently) hardware is doing what it's supposed to do. Open source has a better chance, though, since it has more eyes on it. Open source software is still ahead of the game for security.

In the scheme of things, this issue is embarrassing for the maintainers, but not even a registerable blip on the radar as far as impact is concerned. A few thousand sites out of the billion or so are vulnerable.

If you are going to try and find an open source security bug to slander, next time pick one that's a little more meaningful.

What's the point?

[WaffleMonster]

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.

Doesn't affect OpenSSH

[Zack]

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

Re:Doesn't affect OpenSSH

[gweihir]

It only affects one more-or-less obscure alternate implementation. The mainstream OpenBSD SSH (also the standard on Linux) is not affected at all.

Why can't people write finite state machines

[FeelGood314]

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.

Re:Why can't people write finite state machines

[johnw]

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.

Re:Uh.... Jedi mind trick?

[AC-x]

No Jedi shit is involved here

Server: Authentication please

Client: My authentication was successful, I may enter

Server: Your authentication was successful, you may enter

I think that "Jedi mind trick" is a good analogy.

Which BSD is that?

[raymorris]

You don't happen to be confusing libssh with openssh, or libssh2 are you?

Shodan shows a few thousand servers in the world using libssh, and half of those aren't vulnerable.

Re:Uh.... Jedi mind trick?

[Carewolf]

Except is more like:

Server: Authentication please

Client: Your authentication was successful, you may enter

Server: ??? Okay, thanks

Client enters

A specific scene from the original Star Wars

[raymorris]

In the original Star Wars, Obi-Wan, R2, and C3PO are sneaking through the city when they are stopped by Storm Troopers who are looking for them. The lead Storm Trooper demands to see identification (just as an openssh server would). Obi-Wan responds "you don't need to see his identification". Unprepared for this response, the lead Storm Trooper takes it at face value and announces to the others "we don't need to see his identification".

The next line has become a meme, "there aren't the droids you're looking for".

Re: This & Windows it's gonna be busy at work

[Anonymous Coward]

Why do IoT devices use BSD or Linux?

This. They should be using Windows.