TL;DR – A vulnerability was reported last week in the libssh open source library. We do not use libssh and are not responsible for it. It does not affect SSH.COM software, like Tectia SSH Server/Client. It does not affect OpenSSH as far as we understand. The vulnerability has been patched quickly. All libssh users are advised to upgrade to libssh 0.7.6 or 0.8.4 to eliminate the vulnerability. Find the libssh patch here. Let's explore what this means for us, for the enterprise...
Our official SSH.COM security advisory notice
Security Advisory: CVE-2018-10933
Please note that this Security Advisory is a vulnerability in the libssh library provided by libssh.org. We don't use libssh in our products, so it does not affect SSH Tectia Server. Additionally, we have confirmed that our own implementation of the SSH protocol does not have a similar flaw. For more information please visit the libssh page.
With the official part out of the way, let’s consider what this vulnerability means and how significant libssh is for software developers and security specialists. First, let’s take a step back…
SSH is everywhere
SSH is an elementary protocol in global digital infrastructure. It’s part of the plumbing. SSH client-server tools are used for various tasks from remote system administration to process automation. SSH is in 90% of the world’s datacenters. There are billions of private and public SSH Keys granting access to people and machines in networks in every corner of the globe. SSH helps make business tick and keeps federal government data secure.
The long history of open source SSH
Open source implementations of SSH have been around since the dawn of SSH. SSH.COM founder and SSH inventor, Tatu Ylönen, made the code available to the open source community in 1995. The origins of different open source SSH libraries go back to Tatu’s free SSH 1.2.12 release.
The best-known open source SSH implementation is OpenSSH. It can be traced back the 90’s and was created from Björn Grönvall's OSSH which in turn forked from Tatu’s original v.1.2.12. Unix servers have come with OpenSSH for many years. OpenSSH is in Windows 10.
libssh is a handy tool for developers
Like OpenSSH, libssh is an open source SSH library. However, libssh is not so widely used. libssh is easy to embed, so it is attractive for different kinds of applications. A typical use case might be where a developer wants to add an SSH implementation to the stack, but client/server applications are hard to embed. A library implementation, like libssh, helps developers rapidly integrate libraries. Git, for instance, uses SSH as one of its underlying protocols for authentication and encrypted transfer.
GitHub, the hosted service for Git, is probably the most well-known site that uses libssh. Github have clearly said that their implementation of libssh is not affected by the vulnerability.
"We use a custom version of libssh; SSH2_MSG_USERAUTH_SUCCESS with libssh server is not relied upon for pubkey-based auth, which is what we use the library for. Patches have been applied out of an abundance of caution, but [GitHub Enterprise] was never vulnerable to CVE-2018-10933," Github via Twitter
“GitHub uses libssh to provide an alternative SSH login method for enterprise customers. If GitHub's libssh-based login method was vulnerable, an attacker could have gained access to source code and intellectual property of the world's largest companies." Catalin Cimpanu, ZDNet
SSH is everywhere in DevOps
GitHub is the most popular version control and source code management platform. It was bought by Microsoft this year for USD 7.5bn. GitHub is a household name in software development. It’s found in nearly in every DevOps toolchain.
My company is a software development company that uses DevOps best practice. Our customers in finance develop software. Our customers in retail, transport, energy… they all develop software and they all have one thing in common: they are all embracing enterprise DevOps. This means taking best practice from DevOps to accelerate software development and growth.
DevOps is an attitude and a toolset, but it boils down to best practice in CI/CD (Continuous Integration/Continuous Delivery) and breaking the barriers between development and operations to code faster and better. SSH is used in all DevOps environments. It’s integrated into popular tools, like GitHub, it’s in code repository front ends, it’s used to administer remote access to the cloud for developers, it’s used to orchestrate machine-to-machine connections, and for secure file transfers.
As new services are created in enterprises and by R&D and DevOps teams, they all benefit from the SSH protocol being built-in to secure data-in-transit, process automation and privileged access throughout the DevOps cycle.
All code, not just open source, has bugs
So, re-using open source software is good. Embedding open source code in the stack is a basic part of software development. It’s what it’s meant for, and it helps open up business opportunities.
In 18 years as a developer, I have learnt that It’s hard to make a computer program to work in the first place, let alone make it maintainable or bug-free. From my student days I always remember Roger Pressman’s classic book “Software Engineering” from 2000 that looked at bugs in telephone switch software that had been running in production for years. Pressman’s findings still resonate with me today. Essentially:
There is no such thing as bug-free computer program. All computer programs contain bugs. Even high quality code might have as many as 3 bugs per 1000 lines of code.
All code has bugs. With the amount of code written growing fast, bugs are a reality for all software developers. With internet-facing services and their implementations, and any related security research, it is vital to have the processes in place and the agility to update software when bugs happen. Kudos to libssh.org for getting the patch to the libssh vulnerability out so quickly.
How bad was this bug? Well, the Mariner I space probe bug, that was a bad bug. Losing a USD 135m spaceship to bad handwriting. We can call that careless. The Berkeley Unix finger daemon buffer overflow that spawned the first internet worm. Yes, that was a bad one, and avoidable. But, it was way back in 1988.
The libssh bug was discovered by Peter Winter-Smith of NCC Group:
There is a vulnerability within the server code which can enable a client to bypass the authentication process and set the internal state machine maintained by the library to authenticated, enabling the otherwise prohibited) creation of channels.
Leap Security’s research found that the libssh vulnerability might affect around 3000 servers globally. This is a small number but significant for a handful of companies. I hope they are all patched and secure by the time you read this.
Open source libraries in the enterprise and how to mitigate risk
Of course, we all strive for the cleanest code. There are a couple of questions that arise here: is open source security code a good fit for enterprise DevOps, and how can you mitigate risk when integrating security protocols into the application layer?
The answer is a resounding, yes. Open source software is vital to cost-effective enterprise software development. However, open source security code needs to be handled with care:
> Use OS tools for system automation tasks
When creating new security tools, one should be careful when selecting the building blocks. You should not develop your own protocols, but instead use well-known protocols and implementations. Almost every operating system has a built-in SSH implementation which has been battle tested over the years. It’s always a good idea to use these OS vendor-provided tools for system automation tasks.
> Use well-maintained code for embedded security protocols
If you create a new application that embeds security protocol implementations, pay attention to your protocol implementation. There are several open source implementations of SSH and the SSL/TLS protocols. You should always select a well-known and actively maintained version that has an active developer community. It’s almost always the wrong choice to write your own implementation of a security protocol.
> Have agile processes in place
In both cases – when you use the operating system command line tools, and when you embed a library implementation of a protocol into your application – it’s very important to follow security vulnerabilities and have processes and tools in place to update tools and components if they are affected by vulnerabilities. This will become more important in the future when more and more complex applications are constructed from open source libraries, containerized components and other publicly available tools and libraries.
SSH.COM and enterprise DevOps
We don’t compete with open source code libraries, like libssh.
Our contribution to modern enterprise DevOps comes in the form of our software for e.g. secure file transfers, multi-cloud access, SSH key management and encrypted 3rd party subcontractor session auditing. We actively work with cloud service providers, DevOps consultants, as well as enterprise R&D teams. It’s a fast growing area for us.
If you want to discuss e.g. how to use SSH in your application stack or secure access for DevOps, please get in touch.
Markku
markku.rossi@ssh.com
