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.
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.
Between the Windows authentication bypass that just came and out (again) and this one, tomorrow is going to be a busy day at work.
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
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.
Lots of software doesn't even try.
Think on that when you're installing your smart devices.
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.
This will be fixed real soon now. Nothing to see or hear. Move along. And this is why open source works. Wha? Oh.
This doesn't affect openssh servers or clients. Only *some* things using libssh *might* be vulnerable. A bit overhyped.
A very small fail in some rather stupid projects...
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
... announces it to the world anyway.
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.
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.
god I could go an open sore right now. Maybe even a closed one.
I find it informative that every critique of this vulnerability is modded down, yet every defense of it is modded up.
This is an inexcusable condition - the server trusts the client to say YES I AM AUTHENTiCATED with no other verification
And this is a library that is heavily used by the *BSDs and therefore IoT devices.
https://tech.slashdot.org/comments.pl?sid=12520486&cid=57184660 - Sorry Ray Morris, your nazi propaganda effort was debunked and you then put your name on it anyway. Lying Faggot Nazis ---> Gallows, do not pass go.
www.shodan.io/search?query=libssh
1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
Why do IoT devices use BSD or Linux? The ones I've seen and worked on are all RTOS based (custom or otherwise).
Modded Troll, as I cannot find any evidence of a 'defense' of this situation.
There are several posts commenting that the affected library is not the one most commonly used in Linux, which is not a defense of the broken library at all, just people saying it is not as critical as if first appears to be.
What the actual fuck did any of that mean?
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.
Avantslash: low-bandwidth mobile slashdot.
You sure told him, Comrade Wang!
It's been over 20 years since I was in school as an EE, so maybe they don't teach this to students anymore, or maybe you forgot, but there are actually two main types of state machines: Mealy and Moore state machines.
The Mealy page says:
In the theory of computation, a Mealy machine is a finite-state machine whose output values are determined both by its current state and the current inputs. (This is in contrast to a Moore machine, whose output values are determined solely by its current state.) A Mealy machine is a deterministic finite-state transducer: for each state and input, at most one transition is possible.
and
1. Mealy machines tend to have fewer states:
* Different outputs on arcs (n^2) rather than states (n).
2. Moore machines are safer to use:
* Outputs change at clock edge (always one cycle later).
* In Mealy machines, input change can cause output change as soon as logic is done—a big problem when two machines are interconnected – asynchronous feedback may occur if one isn't careful.
3. Mealy machines react faster to inputs:
* React in same cycle—don't need to wait for clock.
* In Moore machines, more logic may be necessary to decode state into outputs—more gate delays after clock edge.
Not all sequential circuits can be implemented using the Mealy model. Some sequential circuits can only be implemented as Moore machines.[2]
The Moore page says:
In the theory of computation, a Moore machine is a finite-state machine whose output values are determined only by its current state. This is in contrast to a Mealy machine, whose output values are determined both by its current state and by the values of its inputs.
and
* for a Moore machine, each node (state) is labeled with an output value;
* for a Mealy machine, each arc (transition) is labeled with an output value.
Every Moore machine M is equivalent to the Mealy machine with the same states and transitions and the output function ...
However, not every Mealy machine can be converted to an equivalent Moore machine. Some can be converted only to an almost equivalent Moore machine, with outputs shifted in time.
Go home, shill. No one here wants what you're selling.
Most servers are openssh, which doesn't use this. Stop with the hyperbole of this issue. It's a nonnon issue for any modern Linux system
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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!
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.
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".
Im "selling" software that doesnt suck, no surprise you feeetards aren't buying.
Yeah, because there's never been any Close Source issues like this... I'm not buying anything your "selling."
Yep. Github.com uses it. Though they say they are "unaffected by it".. but they still use it.
Yet another reason to stay as far a fucking away as possible to github as possible:
1. Easily hackable in the cloud. Just guess some stupid anus password and you are in logged right into their account.
2. Owned by microshit now. People actually apologized and still use github even though microshit owns it. It's so cute and funny.
3. github.com uses insecure shit libs. I'm sure they use even more. Maybe they've even been rootkitted and they don't know it?
Go ahead, trust your intellectual property to some random company with a for profit interest that anyone can access. You tech types are so smart.
Why do IoT devices use BSD or Linux?
This. They should be using Windows.
Because the core OS components of windows are so bloated it wonâ(TM)t ft, and so insecure a script kiddie could crack them.