We’ve all been there. Some key piece of information is known by some, but not you. It could be a party, an office tradition, or that someone expected you to do something. When you find out, it’s normal to have a sinking feeling, but you adjust and deal with the situation. Plus, if you’re anything like me, you’ll try and figure out how to know about things earlier. After all, there are good surprises and bad, and working to minimize the bad ones should be a priority.
If you’ve read this far, you’re probably wondering what this has to do with my normal posts on security and containers. To answer that, let’s consider the disclosure of a security vulnerability. We know disclosures are published on a daily basis. We also know that some vulnerabilities are branded with snazzy names like Heartbleed, Venom and Shellshock. We further know that some vulnerabilities are more easily exploited or severe than others. In all cases, being the last to know is almost the worst scenario. The worst scenario is of course being the last to know *and* being subject to attack.
Since joining Black Duck in June, I’ve been on the lookout for a perfect vulnerability to track disclosure timelines against. Dirty Cow turns out to be the perfect candidate. For those of you who don’t know, Dirty Cow was announced to the world on October 20, 2016 and hit the press October 21, 2016. It was given the CVE identifier CVE-2016-5195. This is a vulnerability so serious that over a dozen proof of concept exploits have been published. These exploits demonstrate everything from basic privilege through to the ability to remotely trigger the vulnerability, and application isolation mechanisms such as Docker containers are no real protection.
Dirty Cow is precisely the type of vulnerability you need to know about ASAP, because delays in discovery can have real consequences. As it turns out, the system of disclosures itself has significant delays. The authoritative source for CVE information is the National Vulnerability Database maintained by the National Institutes of Standards and Technology in the US. It is from this source that simple vulnerability scanners and manual tools obtain their information. It also happens that if you had performed query against it on November 9, 2016 for the Dirty Cow CVE, you’d have seen no results as shown in the image below.
The NVD was updated on November 10, 2016 to contain information on Dirty Cow and now has the following entry. Note the statement "as exploited in the wild in October 2016," which isn’t overly encouraging.
Looking at the timeline, we see approximately three weeks during which a high profile vulnerability was circulating in the media, had many exploits demonstrating its severity freely available on the internet, but for which no information was available in the NVD. Now I’m not trying to fault the folks over at NIST for the delay; rather I’m trying to highlight that if the NVD is your primary source for information, there’s a good chance you’re at needless risk. Further, if you’re thinking monitoring the media is going to be a sound strategy, they really only pick up on the branded high profile stuff. Serious issues aren’t always going to have that special treatment, and we honestly don’t need more vulnerability brand silliness.
Of course by this point you’re not only expecting me to say “there’s a better way,” but also that Black Duck can help. You are correct, of course. Black Duck does have NVD data as an information source, but we also have multiple additional data feeds; including teams whose job it is to monitor for vulnerability activity that isn’t part of the NVD. This is Black Duck Enhanced Data, and is a key part of our value.
The screen shot below shows the Black Duck Hub view of the world for Dirty Cow. We first became aware of activity leading to the eventual disclosure on October 17, 2016 and published our report on October 20, 2016. This means someone performing a code scan on October 20, 2016 would’ve known about Dirty Cow the day before the media storm started and many days before the explosion of proof of concept exploits. That’s critical to protecting against attacks.
In conclusion, if you have an open source vulnerability solution you need to ask your vendor precisely where they get their information from. If the answer only includes the NVD, then I argue it’s time to look for a better solution. Your business could depend upon it. Don’t be the last person to know when a security vulnerability is disclosed, be one of the first.