GHOST stories, Dirty COWs and IoT Attacks
Three high profile open source security events that happened in 2016 and lessons can be learned from them. With another year under our belts, it’s a great time to look back at open source security vulnerabilities.
#3 — CVE-2015-7547
CVE-2015-7547 is often confused with its its “cousin” vulnerability, CVE-2015-0235 (popularly known as GHOST), as both impact glibc and thus impact a number of applications dependent on that library. The confusion highlights an important lesson. Keeping up with vulnerability disclosures is difficult enough without adding catchy nicknames to the mix. Everyone’s objective should be a clear and concise understanding of whether an issue impacts them, and that starts with knowing the state of your systems. With over 4,000 vulnerability disclosures in the first three quarters of 2016, distractions just compound an already difficult task.
#2 — CVE-2016-5195
CVE-2016-5195 was disclosed in October 2016 with the branding "Dirty Cow" and published in the NVD in November 2016. This was a critical bug for the Linux operating system and impacted most currently deployed Linux installations. At the time of disclosure, conjecture held that triggering the underlying race condition had some ready workarounds, and that it wasn’t remotely executable. Both assertions turned out false, and close to twenty exploits have been published on the Dirty Cow Github project.
CVE-2016-5195 actually teaches us two things.
- Branding can sometimes have a positive impact. While the buzz surrounding Dirty Cow started on October 20th, the entry for CVE-2016-5195 didn’t have a detailed record in the NVD for close to three weeks. The lesson here is to ensure and confirm your security vendor is able to provide you with information at least as fast as the media. If they can’t do that, you need a new vendor.
- Second; with time comes opportunity. In the commit for the fix for Dirty Cow, Linus Torvalds states “what used a purely theoretical race back then has become easier to trigger.” In other words, if a potential security bug is deferred because someone determines it can’t be exploited; that’s a point in time decision. Software evolves and so do skills and hardware. Something that was hard to do only a few short years ago may be trivial today. If you’re deferring security bugs, there’s a real chance you’re creating future weaknesses.
#1 — CVE-2004-1653
Since CVE-2004-1653 was disclosed in 2005, you might question why it holds the top spot for 2016. CVE-2004-1653 is behind both the 620 Gbps attack on Krebs on Security and the Dyn DNS infrastructure cyberattack. With this vulnerability (known for over eleven years), it would be reasonable to expect no modern systems would be impacted. Unfortunately for so very many people, it turns out the most modern of systems, internet connected commercial devices (IoT), are the impacted systems. This is not a case of a long tail, rather a case of misunderstood default configurations.
As I mentioned with Dirty Cow, if someone decides to defer a security issue, that’s a point in time decision with a real opportunity for future exploits. That’s precisely what happened with the various IoT attacks. If you look at the details of CVE-2004-1653, we find OpenSSH has a default configuration that could be exploited. The OpenSSH documentation for the AllowTcpForwarding configuration option states: “Note that disabling TCP forwarding does not improve security unless users are also denied shell access.” While true, this statement requires developers to interpret its meaning, and understand that a well-known default password doesn’t qualify as “denied shell access.”
This makes CVE-2004-1653 the biggest lesson for 2016. Beware of default configurations and take the time to understand the security decisions made by the developers of your dependencies. If they’re making decisions impacting the overall security of your product or service, then it’s your reputation on the line. If you’re in an industry where time to market is critical, then you’re going to be making security trade-offs in the interests of shipping product. If that’s the case, then you owe it to your customers and shareholders to have a clear security story that decreases the potential for your product to become part of the next large cyber-attack.
The use of open source components is the norm in 2016. While there are significant benefits to using open source components in your product or service, you can’t assume their communities function like commercial software companies. Open source project leaders are rarely going to contact you to upgrade, few have security advisory lists and fewer still have dedicated security response teams. This means that security in an open source world is a collaborative effort. You have to take ownership of monitoring for security issues in your dependencies. You have to understand the ramifications of default configurations, and you have to have a defined process to update your product or service when the inevitable security issue arises.
While it can be daunting to inventory your software dependencies, that’s the first step in being able to define your security response plan for product releases. I challenge any product manager reading this to have a resolution for 2017 to do just that, and in so doing create a more prosperous world for their products.