Looks like CVE-2018-10933 was just released today and you can find a summary here from libssh here


libssh versions 0.6 and above have an authentication bypass vulnerability in the server code. By presenting the server an SSH2_MSG_USERAUTH_SUCCESS message in place of the SSH2_MSG_USERAUTH_REQUEST message which the server would expect to initiate authentication, the attacker could successfully authentciate without any credentials.

I am trying to understand this more and its range of impact. Do operating systems like Debian, Ubuntu rely on libssh for SSH and if they do does that mean every server exposing SSH is vulnerable to this attack? Also, does OpenSSH rely on libssh or are they two separate implementations? I tried looking for OpenSSH vs libssh but couldn't find what I was looking for. This vulnerability sounds like the worst case scenario for SSH so I am just surprised it hasn't been making headlines or blowing up. The summary of this vuln is vague so I'm looking for any insight into the range of impact and in what scenarios I should be worried.


... does OpenSSH rely on libssh

OpenSSH (which is the standard SSH daemon on most systems) does not rely on libssh.

I tried looking for openssh v.s. libssh ...

Actually, a search for openssh libssh gives me as first hit: OpenSSH/Development which includes for libssh the following statement : "... libssh is an independent project ..."

Also, if OpenSSH would be affected you can sure that you would find such information at the official site for OpenSSH, which has explicitly a page about OpenSSH Security.

Do Operating Systems like Debian, Ubunutu rely on libssh for SSH ...

See the official documentation of libssh on who is using it (at least): KDE, GitHub...

You can also check which available or installed packages on your own OS depend on libssh. e.g. for Debian and similar (e.g. Ubuntu) this would be apt rdepends libssh-4 or apt rdepends --installed libssh-4.

Note that the use of libssh does not necessarily mean that the product is automatically vulnerable. First, the problem seems to be only relevant when using libssh for SSH server not client. And even in the server role it is not necessarily affected, for example Github seems to be not affected even though they use libssh in the server role.

  • 7
    Since KDE uses it for SFTP I'm guessing they don't use the server code. Must have been fun for GitHub to hear about though... – AndrolGenhald Oct 16 '18 at 18:54
  • 2
    apt on Debian 8 doesn't know about rdepends. There you can use apt-cache rdepends libssh-4 instead. – Arjen Oct 17 '18 at 7:55
  • "is an independent project" is an ambiguous statement. It might mean it's independently developed, but still relied upon/linked. – Grzegorz Oledzki Oct 19 '18 at 7:44
  • @GrzegorzOledzki: I agree that it might be necessary to follow the link I've provided and look at a bit more context of this statement to be sure that libssh is not relied upon or linked into OpenSSH. – Steffen Ullrich Oct 19 '18 at 14:16

Do Operating Systems like Debian, Ubuntu rely on libssh for SSH and if they do does that mean every server exposing SSH is vulnerable to this attack?

The issues may arise with applications that use libssh. As stated on the libssh website: "libssh is a C library that enables you to write a program that uses the SSH protocol." Thus, it is user applications that make use of the libssh library that could be vulnerable, not the operating system itself. Here are some applications that use libssh (from the libssh website):

  • KDE uses libssh for the sftp file transfers
  • GitHub implemented their git ssh server with libssh
  • X2Go is a Remote Desktop solution for Linux

Also, does OpenSSH rely on libssh or are they two separate implementations?

No, it doesn't. They are separate.

Update 2018-10-18: A blog post written by the vulnerability discoverer and including a detailed explanation as well as proof-of-concept code (via Paramiko) is now available.

The linked-to blog post explains that the vulnerability results from the fact that code in the packet processing dispatch table (in libssh\src\packet.c) execute handlers for SSH2_MSG_USERAUTH_SUCCESS even for servers (even though such a message is only supposed to be processed by clients). Further investigation of the code shows that such errant processing of the message in libssh\src\auth.c causes the server to change the session state to authenticated!

Detailed proof-of-concept code is also available, showing that python Paramiko can be updated to send the SSH2_MSG_USERAUTH_SUCCESS message in place of a SSH2_MSG_USERAUTH_REQUEST message and exploit the vulnerability.

However, the blog post also states that:

"Not all libSSH servers will necessarily be vulnerable to the authentication bypass; since the authentication bypass sets the internal libSSH state machine to authenticated without ever giving any registered authentication callbacks an opportunity to execute, servers developed using libSSH which maintain additional custom session state may fail to function correctly if a user is authenticated without this state being created."

  • 1
    "OpenSSH states that they use parts of LibreSSL (the libcrypto part), but not libssh" - in the link you provide OpenSSH only states that it uses LibreSSL. It does not state that it does not use libssh and in my opinion this conclusion can also not be drawn from what they write there. – Steffen Ullrich Oct 16 '18 at 19:17
  • 1
    -1: the only thing libssh and LibreSSL have in common is that both names begin with "lib". – Mark Oct 16 '18 at 20:59
  • 2
    @Mark: how does "...hey use parts of LibreSSL [], but not libssh." even suggest otherwise? – Guntram Blohm Oct 16 '18 at 21:17
  • 1
    @Mark they also both have double s in their names, and are both crypto-related. – Paŭlo Ebermann Oct 16 '18 at 21:20
  • 4
    okay... updated answer to... uh, make it better. LibreSSL has nothing to do with libssh, that's the point and I was pointing that out... I guess that was confusing. – hft Oct 16 '18 at 22:05

To view an application's dependencies via the command line you can run the following command:

ldd /usr/sbin/ssh

This will show any dependency of the said application. When this command is executed it doesn't show libssh meaning libssh is not a part of OpenSSH.

  • 5
    Unless it's statically linked (it's not, but just by running ldd you couldn't be sure). – AndrolGenhald Oct 17 '18 at 14:26
  • @AndrolGenhald, you can do mixed linkage: static linkage of some libraries, and dynamic linkage of others. – Mark Oct 17 '18 at 22:41
  • 1
    @Mark I know, I mean that OpenSSH doesn't statically link libssh, but running ldd wouldn't tell you that. – AndrolGenhald Oct 17 '18 at 23:40

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.