OpenSSH is regarded as the most widely used SSH library, and would rival for top adopted open source products with significant numbers of enterprise vendors wrapping it into their network and security products. It wasn’t that long ago that we saw the release of CVE-2014-0160 which is more well known as the Heartbleed vulnerability or the OpenSSL product. This last week saw a new vulnerability hit the community as noted on the release notes for OpenSSH as a patch note. Along with the patch release, there is also a note about how to mitigate the client issue by adding the UseRoaming directive in the ssh_config file in OpenSSH.
Qualys also released its own advisory with some more details on the potential exploit which may already have been in use in the wild. To be subject to the vulnerability, the client must connect to an exploited server which could then pick up the private key from the client side.
Because the risk of this OpenSSH vulnerability is on the client side library which means a reduced chance of being exploited compared to a server side vulnerability. It still presents a risk and highlights the importance of the community bringing these to the public eye. What it highlights more than anything is that vulnerabilities are release often, and we need to be prepared to mitigate and resolve them as quickly and safely as possible.
New Vulnerabilities need New Operational Practices
Looking back on the Heartbleed, you would think that we learned our lessons. That isn’t the case as it turns out as noted in the Quay.io blog which is part of the CoreOS container registry:
“We have already scanned millions of containers on Quay with this feature, and found that nearly 80% are subject to major vulnerabilities, such as Heartbleed.” as noted in November 2015 by Joey Schorr, co-founder of Quay.io (acquired by CoreOS in 2014).
Vulnerabilities are a reality. If you believe that your product is not vulnerable, you may be disappointed. Some may say that calling yourself invulnerable is a Titanic claim. The unsinkable ship sank, and the product that claims to have no vulnerability is one which just may not have been discovered yet. We should assume in our IT practice that everything is vulnerable and move towards a detection and remediation stance.
Adding configuration management into your everyday operational processes is a must for OpenSSH. Pick your tool, and make it work. There is no right or wrong tool to use as long as the process is firmly implanted into the workflow for your applications and infrastructure.
Scanning your environment to ensure that versions are up to date is also a critical step needed. Even the best configuration management system can be prone to error at some point in its operations. Making sure that we use the same methods that drive good development (build – measure – learn) we can run configuration management to deploy changes and fixes, measure the results, and then the learn part comes with our experience in figuring out anything that may have impacted the patch deployments.
Open source can often take the brunt of these sorts of vulnerabilities, but we also know that the response from large open source implementations such as OpenSSL and OpenSSH is usually swift and complete.
So, if you use OpenSSH, make sure to download and test the latest release to ensure you are protected in this case. This is a good sign that it was caught without any large scale issues being reported. Let’s just make sure that we don’t look back in a year or two and wonder why the patches didn’t make it out. Heartbleed and the lack of remediation should stand as the biggest driver for IT operations teams to make sure their security management practices are up to speed.
Check out some of our other topics here.