Sophos Cloud Optix
Big, bad, scary bug of the moment is CVE-2018-10933.
This is a serious flaw – in fact, it’s a very serious flaw – in a free software library called libssh.
The flaw is more than just serious – it’s scary, because it theoretically allows anyone to log into a server protected with libssh without entering a password at all.
It’s scary because ssh, or SSH as it is often written, is probably the most widely deployed remote access protocol in the world.
Almost all Unix and Linux servers use SSH for remote administration, and there are an awful lot of awfully large server farms out there, and so there’s an awful lot of SSH about.
SSH stands for secure shell, where the term shell is Unix-speak for a command prompt, the place where most Unix-style system administration functions are performed, whether manually by a logged-in human, or automatically via a logged-in script.
But SSH is used for much more than just shell logins because it creates what’s often called a secure tunnel – a general-purpose encrypted data channel between two computers on the internet.
Notable uses for SSH include secure file transfer between servers, and secure data synchronisation between data centres.
Security holes in SSH are therefore the stuff of nightmares for many sysadmins out there, and this one has certainly got the security newswires buzzing.
The good news
Here’s the good news.
By far the most commonly used SSH version out there is an open source product called OpenSSH, created and maintained by the security-conscious folks at OpenBSD.
OpenSSH is a completely separate implementation to libssh – they don’t include or rely on each other’s code.
Other well-known open source implementations of SSH include Dropbear (a stripped down version commonly used on routers and other IoT devices), libssh2 (it’s a different product to libssh, not merely a newer version) and PuTTY (widely used on Windows).
None of these projects have this bug either, so most of us can stand down from red alert.
The only really big, mainstream project we know of that uses libssh as its SSH server is Microsoft’s GitHub source code repository.
And the good news there is that the GitHub project [a] doesn’t actually call the buggy code in the libssh product and [b] has installed the patch anyway, just to set everyone’s minds at rest.
Another very widely used software tool that supports libssh is cURL, a command-line web data transfer tool that is shipped on every Mac, included in almost every Linux distro, and widely used for automating uploads and downloads on IoT devices.
But cURL doesn’t include SSH by default; isn’t usually used on servers to process incoming connections; and anyway cURL uses libssh2 as its first choice if you need SSH support.
The bad news
The bad news is that any server that is listening out for incoming SSH connections using libssh is at considerable risk of unauthorised access.
The bug is comically bad, and in very simple terms it goes like this.
When logging in, the client is supposed to chat to the server along these lines…
Client → Server: HELLO-I-WOULD-LIKE-TO-START-AUTHENTICATING
Client and server: [...a careful cryptographic dance is done by
both sides to verify login credentials...]
Server → Client: WELCOME-YOU-HAVE-PASSED-THE-TEST
…and then both sides can begin to send data to and fro.
But the bug means a client can just talk to a libssh server like this…
Client → Server: WELCOME-YOU-HAVE-PASSED-THE-TEST
…and then both sides can begin to send data to and fro.
In other words, if the client tells the server that authentication is complete, rather than the other way around, the server happily believes it.
No password requested or required.
What to do?
- If you have any software product that includes or uses libssh, download and install the latest libssh version at once.
- If you use a product that has libssh built in, rather than supplied as a shared library or DLL, you will need an updated version of the app itself.
- If you aren’t sure, consult the product’s documentation or online community.
For more information, watch our video discussing the issue and what to do about it:
(Watch directly on YouTube if the video won’t play here.)
This smells like some sort of quick-test-workaround that was accidentally left in past the testing stage.
I think it’s just a consequence of state machines to control the operation of a protocol being hard to get right. State machines are like parsers: it’s easy to show that your code will recognise correct sequences but hard to show that it will reject erroneous ones.
The bug is almost comically bad
The defense moves to have the extraneous word almost stricken from the record…
Fixed, thanks.
Heh. I wasn’t thinking so much that there’s an error…as much as reading the description made me laugh out loud. Decidedly comical.
I’d say that’s less “asking nicely” than “striding confidently.”
To hack a server, you need only be a digital Ferris Bueller.
Congratulations – you just won the internet for today. Your prize is in the form of a short lived cryptocurrency that will actually cost you to receive… enjoy!
So this is basically clickbait: a serius bug for a popular protocol was found in an obscure implementation of it that virrually nobody uses, or has already updated.
Tell that to people with projects that do use libssh. (There are a lot more than you probably think, so your words “virtually nobody” are unfair.)
Also, given the uncertainty amongst concerned users online, getting across the message that this doesn’t affect OpenSSH (different code) or GitHub (same code but the buggy part is never called), seems pretty purposeful to me.
I don’t buy the idea that cybersecurity blunders are “clickbait” unless they affect huge numbers of people. In your world we’d ignore data breaches like Facebook’s recent access token leak for 30,000,000 users – heck, 97% or more of Facebook accounts weren’t affected, so it’s just bad luck for the tiny 3% of users who were…
I would argue however that by adding lib to the headline of your article, you could improve your accuracy while reducing the chances that colleagues of ours will be spending their mornings today talking execs, auditors, etc down from the position that every ssh server is vulnerable.
Yes, if you are using libssh you should patch NOW, but probably 80-90% of firms aren’t. The scariest problem is if your infosec dept doesn’t know because they’re not tracking assets at the library level.
I pondered this very point. Saying “libssh” still doesn’t help if you don’t know [a] that libssh is not “the ssh library that most products use” [b] which products contain libssh [c] how to tell.
I decided to say just “SSH”, which is not the name of any individual product, in the hope of keeping it general enough that anyone who had seen this story in mainstream media would recognise it, but with enough specifics in the article itself actually to help everyone through points [a], [b] and [c] above.
I just don’t think that it was this headline that scared your execs, auditors, etc. *up* to the position that every ssh server is vulnerable, but I do think that if they read this article (or had it point out to them) they’d have a decent overview of all the nuances in the story.
In our video about the bug, we did say “libssh”…
https://nakedsecurity.sophos.com/2018/10/18/the-libssh-login-with-no-password-bug-what-you-need-to-know-video/
…given that we have already general coverage by means of this article.
Any idea how long the bug has been around?
According to libssh, versions from 0.6 onwards have the bug. The oldest (in fact, the only) 0.6 release tarball in the libssh download repository is 0.6.4, dated 2015-03-03…
…so “at least 2.5 years”, I’d say.
Makes you wonder how many other tools have similar bugs/mistakes written by the same developers.
Seriously funny.
…or other developers entirely. No doubt this sort of error (albeit in hindsight is comical as Duck mentioned) is easy to implement when you’re testing for other aspects of the same interaction.
Looks like you completely missed the most important piece of information: which versions are affected and which versions contain the fix. Fortunately your first link has some information about that (and the libssh home page too). Also I assume that libssh built without server support (as I’ve always had it) is not affected.
I was going to try to list everything here but I figured the vast majority of libssh users will have it compiled into (or as a dependency of) some other software they’ve installed, and the creators of that software are the people to ask…
As far as I can tell, the bug has been in the libssh code from version 0.6 onwards. There are patches published for the 0.7 and 0.8 series, but not for 0.6 that I can see, so if you have a product that uses libssh 0.6.x then that product will need to migrate to 0.7 or 0.8 and adopt the latest release in that series.
Most products that use libssh seem to work in client mode only (it’s only when the code answers an SSH connection that the bug can be triggered), but not all.
The product I’d like to know about – can it operate as a server or just as a client? – is KDE, not being a user myself. It speaks SFTP in its file manager, using libssh, but I assume it doesn’t talk from file manager to file manager and therefore doesn’t have a server mode… can anyone comment?
You still didn’t mention the relevant version numbers: 0.8.4 and 0.7.6 contain the fix.
As a Gentoo user, I compile everything on my computer (except very few proprietary programs), and libraries are not linked statically.
I have libssh installed as a dependency of SFTP support in kio-extras (from KDE) and ffmpeg, nothing else. And it was built without server support by default, so that part is obviously not needed by KDE.
The point is you want *the latest* 0.7 or 0.8. Given that people may read this article tomorrow, next week, next month, by which time there might be another update (after all, it’s not unknown for updates that are hurried out to fix one problem to need updates in short order).
Check with libssh and “the relevant version numbers” will be the current ones…
Thanks for the feedback on KDE (and ffmpeg, which IIRC has SSH support for streaming video *to* SSH servers and thus has no need of server-style SSH support).
Which rights do I have after an successful exploitation? root?
I’m not actually sure – I suspect you get the uid of the server, which ought to give you minimal power, though that would depend on the implementation of the server itself.
Clickbait. You should lead with basically no ssh server uses this.
Basically, that’s untrue. Check Shodan… you might be surprised.
When I read Microsoft’s GitHub, it took me a moment to realize you were talking about the service itself and not the Windows version of OpenSSH that Microsoft maintains on their official GitHub account, and that ships with Windows 10 and Windows 2016/2019.
Yes – I meant GitHub The Whole Thing That Now Belongs To Microsoft.
The Windows build of OpenSSH is, of course, not libssh based…