[This was originally published on RiskBasedSecurity.com.]
Earlier this week, Andreas Schneider announced the release of a new version of libssh, covering “an important security” that addressed “an authentication bypass vulnerability in the server code”. Pretty quickly we saw several news articles published that covered this issue, as well as third-party blogs that added commentary on the technical side of the vulnerability. Since we were following the issue closely, we wanted to share some of the meta-information we tracked as well as commentary from the ‘social side’ of this disclosure.
First, a few basics and quick recap. This appears to be the first libssh vulnerability disclosed in 2018. Last year there were at least two vulnerabilities disclosed in libssh2, a different project. Prior to that, in February 2016, a vulnerability was disclosed that impacted both libssh and libssh2 likely due to common code. For this new vulnerability, there has been immediate speculation on how bad this vulnerability is considering Github and others might be using the code, with Github providing a quick response addressing the concerns. While there is a CVE assigned for this vulnerability, it lacks a lot of references that give great additional information as far as the technical details and products impacted. Others are wondering why an issue this serious didn’t earn a CERT advisory, or since so many believe it is a critical issue, at least a CERT-VU. As expected, regardless of the potential severity we are seeing some people getting fed up with sensational headlines around vulnerabilities trying to scare consumers to get those ad revenue generating clicks.
How prevalent is libssh? According to their homepage, it is used in KDE, GitHub, and X2GO. Additionally, we know that most of the Linux distributions use it, including Debian Linux, Red Hat Enterprise Linux, Ubuntu, SUSE, and openSUSE. Further, Puppet Enterprise, F5 BIG-IP, and F5 BIG-IP AFM also include it in their products. Based on a cursory look at VulnDB entries for libssh and libssh2, it appears that more companies adopt libssh2, including IBM, Xerox, Oracle, and Symantec. As vendors take time to process the libssh vulnerability, we will start to see their own advisories on the issue, such as from F5 confirming that some of their Big-IP Advanced Firewall Manager products are vulnerable and could allow unauthorized logins.
Authentication Bypass Vulns Everywhere!
Steve Christey Coley, who worked on the CVE project for 17 years, points out that people are quick to make fun of “easy auth bugs” because “yes, some are simple”. He also points out there is “very little research in detection & prevention for these kinds of logic/control/state-machine flaws vs buffer overflows, injection, etc.” in the thread by citing a trivial remote authentication bypass vulnerability that impacted AIX, IRIX, and Slackware Linux from 1994. He makes a great point. This type of vulnerability should be just as easy to find by researchers as any other, given the time that has passed and the tools readily available today. But as we have learned, this libssh issue is over four years old and just now being found and disclosed.
Dominic White shared “a brief and incomplete history of embarrassing auth bypass bugs:”
It’s clear that some researchers are now focused on finding more of these types of issues though. Twitter user Aris Adamantiadis points out the “exact same bug was found in paramiko a month ago” and that it is an “interesting pattern”. It’s true that the particular Paramiko vulnerability he references is eerily similar to the new libssh issue. In fact, a quick skim of VulnDB vulnerability titles reveals remote authentication bypass vulnerabilities in Juniper Junos, Responsive FileManager, Cisco Digital Network Architecture, Cisco HyperFlex System, Cisco IOS XE, IBM Rational Engineering Lifecycle Manager, Neo4J Server, and Symantec Messaging Gateway. All of these vulnerabilities disclosed in the past month!
Doom & Gloom?
When a vulnerability is disclosed that potentially impacts a lot of organizations, or it is trivial to exploit, we tend to see a wide variety of headlines and commentary about how the issue is critical. Does this new libssh disclosure warrant the “doom & gloom” type of Tweets and headlines that suggest a vulnerability is really bad without disclosing additional details that may mitigate the concern? For example, in response to the libssh vulnearbility, GitHub confirmed that while they do use the libssh code, they are not vulnerable due to how they use the code. In a further statement, Github shared additional information that stated they are actually using a custom version of libssh.
This example stresses that it is important to understand how a third-party library is integrated into a product, if it has been customized, and even if a vulnerability can ultimately even be triggered. GitHub has provided a clear example as to why some vendors will release advisories on such issues that ultimately say “we are not vulnerable”.
Twitter user Bob Rudis cites Project Sonar Scan data that suggests there are around 5,500 Internet-facing vulnerable libssh nodes, saying that amount “isn’t too bad”, but then immediately concludes they are “all vulnerable to the auth bypass issue, so consider them pwnd”. Twitter user Rob Graham points out that “while SSH is used everywhere, libssh is not so common” and that “it’s usually client-side”. The important point here is that this new libssh issue affects server side implementations only.
Source: https://twitter.com/hrbrmstr/status/1052318521236094976
Ultimately, over the coming months we suspect that we will see additional vendors address this issue in advisories or release notes as they determine if they are impacted. Until then, use common security practices like network segregation, ACLs, and internal auditing to test if a system is vulnerable manually or try using a newly-published scanner.
The Anthropomorphization Of A Vulnerability
Most commonly associated with human behavior toward animals or material objects, to anthropomorphize, or to “ascribe human form or attributes to (an animal, plant, material object, etc.)” [Dictionary.com] can apply to computer activity. Perhaps one of the best known examples of this is an interaction captured in a single panel XKCD cartoon:
With the disclosure of the libssh issue, one of the curious trends that caught our eye was the same type of anthropomorphization of this vulnerability happened quite a bit, almost all in the same manner. There is clear value in doing this in many cases, as it can sometimes better explain the simplicity of the exploit to a non-technical crowd. But as we all know, we must also be careful when over-simplifying and using analogies that are too far-reaching as they could lead to misinterpretation.
The common theme in the libssh tweets can be seen in Tweets from @dev_console, @0xAmit, and @sphinxgaiaone, but our favorite came from @DAkacki:
This takes a fairly simple vulnerability, in concept, and converts it to a human interaction to explain it. As you can see from the Likes and Retweets, it has received positive attention. This shows that this approach can be an effective way to help explain the issues while also underscoring the severity of an issue, or at least, the exploitation of it. However, most anthropomorphisms that we have seen thus far don’t attempt to speak to the actual impact by addressing how many servers are actually vulnerable or if there are mitigating circumstances among other things.
What’s Next?
This new libssh vulnerability didn’t get a name or a fancy logo, but it sure did receive media attention as if it had. It also was the focus of quite a few blog posts and several articles that made it appear that this vulnerability was going to cause substantial impact to organizations, and at first, incorrectly, to all GitHub users. While this particular libssh vulnerability has also been rated a base CVSS score of 10, there is still debate in the security community as to whether this bug has been overhyped or not. Regardless, if you are running the server side implementation of libssh we recommend that you do your own analysis to see if the vulnerability can be triggered and update accordingly.