Submitted via IRC for Bytram
Trivial authentication bypass in libssh leaves servers wide open
There’s 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. While the authentication-bypass flaw represents a major security hole that should be patched immediately, it wasn’t immediately clear what sites or devices were vulnerable since neither the widely used OpenSSH nor Github’s implementation of libssh was affected.
[...] 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.
[...] Rob Graham, who is CEO of the Errata Security firm, said the vulnerability “is a big deal to us but not necessarily a big deal to the readers. It’s fascinating that such a trusted component as SSH now becomes your downfall.”
Winter-Smith agreed. “I suspect this will end up being a nomination for most overhyped bug, since half the people on Twitter seem to worry that it affects OpenSSH and the other half (quite correctly!) worry that GitHub uses libssh, when in fact GitHub isn’t vulnerable,” he said. “Remove GitHub and my guess is you’ll be left with a small handful of random sftp servers or IoT devices and little else!”
[...] The SSH2_MSG_USERAUTH_SUCCESS message is used by the server to inform the client that they were authenticated successfully, it updates the internal libssh state machine to mark the client as being authenticated with the server. What I found was that if the exact same message is sent to the server it updates the state machine to tell the server the client is authenticated.
Technically: I would say that it’s surprising how fairly straightforward bugs with serious consequences can still lurk, and sometimes it pays to take a step back from fuzzing to try to understand how a protocol implementation works.
Again, anyone who runs a vulnerable version of libssh should patch immediately. And anyone who used the app to receive incoming connections from untrusted users should consider closely examining their servers for signs of compromise. At the same time, all indications at the moment are that the number of devices affected by this high-severity bug appear to be relatively small, a limitation that's being lost on many people discussing this bug over social media.
(Score: 3, Informative) by Anonymous Coward on Thursday October 18 2018, @12:38PM (1 child)
# telnet myserver.tld 22
Connected to myserver.tld.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.5 FreeBSD-20170903
If your implementation relies on libssh then you should see it listed in the bold line. Using telnet to check your ssh server for the latest CVE... ironic.
(Score: 2) by hendrikboom on Thursday October 18 2018, @09:54PM
Devuan ascii, and presumably Debian appear to use OpenSSH too instead of libssl.
(Score: 2) by VanessaE on Thursday October 18 2018, @01:00PM (1 child)
You don't say? Wow, I would never have guessed. I suppose wet water is wet, and bright LEDs are bright, too?
(Score: 4, Funny) by Gaaark on Thursday October 18 2018, @03:19PM
and the TARDIS is bigger on the inside.
--Wait... what are we doing here?
:)
Re-watching Doctor Who: LOVE the first doctor!
--- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---
(Score: 2) by VLM on Thursday October 18 2018, @01:39PM (2 children)
https://www.libssh.org/features/ [libssh.org]
Does anyone use the server side code? Perhaps they censored the web page to only list client side code users when they learned about the bug, or maybe its code nobody uses so it had a huge hole for a long time.
I've not been successful at finding anything using the vulnerable server side code. Surely there must be some obscure embedded appliance using it or something like that.
(Score: 4, Insightful) by rob_on_earth on Thursday October 18 2018, @02:09PM
Shodan reported 6000+ matches.
https://arstechnica.com/information-technology/2018/10/bug-in-libssh-makes-it-amazingly-easy-for-hackers-to-gain-root-access/ [arstechnica.com]
But if there is only one and it happens to be the nuclear launch system or the internet fridge holding my lunch, then it is the end of the world!
(Score: 1, Interesting) by Anonymous Coward on Thursday October 18 2018, @02:41PM
https://www.shodan.io/search?query=libssh-0.6.0 [shodan.io]
At least a few servers out there using it...
(Score: 4, Informative) by NotSanguine on Thursday October 18 2018, @03:17PM
The advisory from the libssh folks can be found here:
https://www.libssh.org/security/advisories/CVE-2018-10933.txt [libssh.org]
From the advisory:
The flaw has also been assigned a CVE:
CVE-2018-10933
https://nvd.nist.gov/vuln/detail/CVE-2018-10933 [nist.gov]
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 4, Interesting) by bob_super on Thursday October 18 2018, @05:07PM (2 children)
> left with a small handful of random sftp servers or IoT devices and little else
Only a few hundred thousand zombie Furby and irrigation controllers forever primed for botnet harvesting !
When do we get a law imposing penalties on unmaintained IoT junk ?
(Score: 3, Insightful) by hendrikboom on Friday October 19 2018, @12:29AM (1 child)
There are already a lot of unmaintainable IoT things already out there. Yes, there ought to be a law.
But it could be hard to take an eight-year-old girl's furby from her. Just how *do* you security-upgrade a furby?
(Score: 2) by bob_super on Friday October 19 2018, @04:09PM
Tazer
Hammer
Fire
Nuke from orbit, to be sure