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.
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 & Windows it's gonna be busy at work tomo (Score:2)
Between the Windows authentication bypass that just came and out (again) and this one, tomorrow is going to be a busy day at work.
Re: (Score:2)
Why do IoT devices use BSD or Linux? The ones I've seen and worked on are all RTOS based (custom or otherwise).
Re: (Score:2, Funny)
Why do IoT devices use BSD or Linux?
This. They should be using Windows.
Which BSD is that? (Score:3)
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: (Score:3)
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.
Re: (Score:3)
Except is more like:
Server: Authentication please
Client: Your authentication was successful, you may enter
Server: ??? Okay, thanks
Client enters
Re: (Score:2)
This is a rather obscure implementation of the ssh protocol, and in particular not the well-reputed OpenBSD implementation. Probably almost nothing is affected, calm down.
Re: (Score:2)
More like lying. No Jedi shit is involved here, just giving a response that someone who was writing something for free neglected to plan for.
Also, this is an example of how many eyes make bugs shallow in OSS. This bug was out there, just waiting to be exploited, until an eagle eyed (and Star Wars enameled) OSS Batman caught it, ninja like, and saved the world from yet another FUCKING IDIOT OSS DEV WHO TRiED TO RECREATE the GODDAMN WHEEL
FUCK
I would say it is more like a Bug's Bunny routine. The client switches to pretending to be the server halfway through negotiations, tells the server it has been granted access to the client, which the server accepts thinking it must be the client then, and the real client then logs in while the server is confused.
A specific scene from the original Star Wars (Score:3)
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
OpenBSD OpenSSH not vulnerable (Score:5, Informative)
Re: (Score:2)
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
Re:OpenBSD OpenSSH not vulnerable (Score:5, Informative)
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: (Score:2)
Re: (Score:3)
You are welcome. The alarmist headlines and missing information this gets reported with are an utter disgrace.
Re: (Score:1)
Yea what was even using that libssh? PalmOS?
Re: (Score:2)
Literally everything before the Heartbleed bug.
Re: (Score:2)
You're thinking of SSL, this is SSH.
Re: (Score:2)
One would think that was a rather extreme difference...
How about Dropbear? (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Move to gitlab. Works better and not owned by MS. github is a has-been. Like anything MS touches, it has turned to shit.
Re: (Score:2)
Actually, OpenSSH in general is safe.
Re: (Score:2)
A very small fail in some rather stupid projects...
Security is hard even if you're trying. (Score:2)
Lots of software doesn't even try.
Think on that when you're installing your smart devices.
Re: (Score:1)
I note that you're quick to jump on the "omg open sores" bandwagon while ignoring that several other people have pointed out no open source distros used this libssh version. Your job must not rely on meritocracy either.
Re: (Score:2)
Yes, this guy is so insightless it is staggering. There is a lot of really bad FOSS out there, but anybody with a clue knows what to use and what not, because it is pretty obvious. His hate fits nicely in with his lack of clue though.
Re: (Score:1)
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.
Re: (Score:1)
Are you stupid? If somebody doing engineering selects an inferior product, then that person is in no way a "victim". The appropriate word is "incompetent".
This is a no-amateur zone as this is a library and in no any way targeted at end-users. In engineering, people are responsible for their choices.
What's the point? (Score:3)
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 (Score:3, Informative)
This doesn't affect openssh servers or clients. Only *some* things using libssh *might* be vulnerable. A bit overhyped.
Re: (Score:1)
A bit overhyped.
a bit understated.
Re: (Score:2)
You're just jealous that his refrigerator is smarter than you.
Re:Doesn't affect OpenSSH (Score:5, Informative)
It only affects one more-or-less obscure alternate implementation. The mainstream OpenBSD SSH (also the standard on Linux) is not affected at all.
Ars Technica discovers patched bug... (Score:1)
... announces it to the world anyway.
Why can't people write finite state machines (Score:5, Interesting)
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 (Score:4, 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.
Re: (Score:2)
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"?
Re: (Score:2)
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
Well ... (Score:2)
www.shodan.io/search?query=libssh [shodan.io]
Re: (Score:2)
Yes ... but your server's Lights Out/Remote Management module might be running a embedded OS with LibSSH.
Citrix had the "//" bug (Score:1)
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!