What's Going on With libssh and What Should We Expect in the Near Future?

Recently, it was discovered that the well-known libssh library had a serious security vulnerability. This vulnerability, known as CVE-2018-10933, allowed clients to get unauthorized access to libssh-based servers. This vulnerability has been fixed in versions 0.8.4 and 0.7.6. The more widely used 0.6.x branch is vulnerable but does NOT have a new release available, though a patch appears to be published by libssh.

While libssh is used in clients as well as servers, the vulnerability only affects servers. At the heart of the coding error is a bug that allows a client to simply tell the server it has already been authenticated. The server then trusts this information and allows the client to proceed without authentication.

In the next few weeks, you should expect major companies to issue updates and patches to their software and hardware systems. If the response to Heartbleed and the recent Struts2 vulnerability teaches us anything, it is that we should expect an initial flurry of fixes followed by a long tail of releases over many months. We should also expect certain legacy systems to remain unpatched either because the original vendor is unaware of their usage of libssh or that they are no longer around to issue a fix. We will also see companies miss the notice that a patch is required.

Beyond standard applications, organizations should examine Virtual Machines, Containers, and Embedded Systems to see if they are affected.

Since this vulnerability affects Internet servers that report their version string when queried, it is possible to use a network scanner to find instances that are running on both on your network as well as on others. For example, the Shodan.io search engine currently shows 6,238 publicly visible libssh servers — of which 1,920 appear vulnerable to this attack. The other versions are older versions, which while not vulnerable to this attack, may be affected by previous vulnerabilities.

The interesting thing about the results visible on Shodan.io is that the versions appear to be highly skewed to the 0.6.0 release, which first came out in January of 2014. This behavior is commonly seen when a new major version of a library comes out. Developers select it, but then do not keep up with patches or updates. The type of vulnerability as seen in CVE-2018-10933 should cause the 0.6.x versions to disappear or be patched over time. There is always the case that the versions advertising themselves as 0.6.0 have been patched without having their version numbers changed. While this type of targeted patching can be commonly seen, it may fall out of style since it prevents the easy understanding of what version is actually being used in production.

Another thing to be aware of is that libssh is commonly seen in other open-source projects, often as a client. In the "used as a subcomponent world," we see a bias to the 0.6.3 and 0.6.4 versions, which came out in 2014 and 2015 respectfully.

What Comes Next?

We should expect to see similar attack vectors investigated in other open-source server software as well as more visibility put on libssh in an attempt to discover other coding errors. It would not be a surprise to see a flurry of similar defects surface in the next few weeks, either rising to the level of a CVE or quietly fixed behind the scenes.

Most people are using an unrelated open-source project known as OpenSSH, which is NOT affected by this vulnerability, though you should not be surprised if your users get them confused and ask about your use of SSH and patching against this vulnerability. You should take this time to collect your usage information of SSH related packages and upgrade to fixed vulnerabilities as needed.

As a customer or user of other organizations' products, you may want to use this vulnerability as a chance to see how your vendors deal with disclosure, patching, and continuous updates after the initial flurry of work are done. For example, after the Heartbleed vulnerability was discovered, there was rapid movement to discover and patch OpenSSL where used, but in many cases, further patching was not performed with the same attention and vigor. Flexera's data shows that there are many instances of OpenSSL, which appear to have been patched right after the Heartbleed fix was published but were not upgraded again.

This defect draws attention to the fact that most companies are still unaware of what open source and other third-party software they are using to build their applications. Flexera's data shows the typical team only tracks 3 percent of the actual libraries they use, which leaves them open to vulnerabilities, open-source license compliance problems, and inefficiencies of dealing with hot vulnerabilities one at a time.

For more vulnerability details, check out this link. Click here to access the libssh project page.