If you could visualize the code that comprises our current technology landscape, you might imagine in your mind’s eye a glowing field of interconnected lines with bright bits of information flowing along the lines’ paths. Here and there, you might see flaws in the network–places where human error have introduced gaps and openings among the lines.
These would be the vulnerabilities–the buffer overflows, the race conditions, and authentication weaknesses–that can enable those who don’t belong here to plug in and steal or control that data running along these lines. Look closer, and you will soon see that while these gaps and breaks share some similarities, they are all unique in the way they can damage an application or service and let malicious people in or unsuspecting users to release information they would rather keep to themselves.
This is a world where Kurt Seifried lives, seeking better ways to identify and catalog these vulnerabilities so that he and others can properly repair these holes and ensure they they are closed for everyone using that software. But that is a landscape overflowing with holes and flaws, so Seifried and his associates are building a new system that will help identify these flaws much faster: the Distributed Weakness Filing Project.
The current method of identifying vulnerabilities lies within the purview of the MITRE Corporation, which administers the Common Vulnerabilities and Exposures (CVE) program. The MITRE-held data is regarded as the true, canonical source of CVE data, which is funded by the U.S. Department of Homeland Security.
CVEs are also just one part of the National Vulnerability Database (NVD), maintained by the U.S. National Institute of Standards and Technology (NIST). The NVD maintained by NIST essentially has a copy of the CVE to which additional data is added, such as CPE (a systematic catalog of product names/versions) and CVSS (vulnerability scoring information) data. The addition of CPE data makes it much easier to identify things that are vulnerable, and the CVSS scores give a hint as to severity and what needs to be prioritized.
The NVD is then used by the U.S. government (and many others) as the source of their vulnerability data.
A CVE, Seifried, a senior software engineer at Red Hat, explained, acts as a “barcode number for a vulnerability,” enabling security professionals to keep track of the many vulnerabilities that are discovered on a daily basis. Seifried highlighted the cross-scripting vulnerabilities found within the PHP programming language.
“There are lots of PHP vulnerabilities,” he said, “but you have to know which one you’re dealing with when trying to patch.”
It is important to note that CVEs comprise a taxonomy of vulnerabilities, not exploits. Exploits like “Heartbleed,” “Ghost,” and “Shellshock”–not to mention all the unnamed exploits which exist–are themselves based on one or more vulnerabilities. In the world of security, the vulnerability, no matter what type it is, is the atomic unit of code problems. Each CVE entry tightly identifies the vulnerability, with a clear index year, descriptor, reference URLs, and, hopefully, any fixes that have been created. MITRE and other participating organizations try to keep the fix data complete and up to date but, Seifried added, “it’s a long ways from complete.”
The need for such a comprehensive database is clear when you examine the huge scope of the software developers have to track. Red Hat alone, Seifried estimates, ships around 120 products in any given year. Just one of the products: Red Hat Enterprise Linux, is comprised of about 9,000 individual open source projects’ code bases. It’s not just a Red Hat problem: Seifried estimates Debian GNU/Linux has 40,000 packages, and Ruby gems and Node.js have 50,000 packages each. Without a clear index of bugs and flaws, it would be incredibly difficult to determine which bug affects which project, and the enterprise products that are created from these projects.
The CVE system, since it is funded by a U.S. government agency, tends to be U.S.-centric. But its usefulness has made it a go-to system for organizations to use worldwide. To facilitate this, organizations can volunteer to be CVE Numbering Authorities (CNAs), which are authorized to assign CVEs to vulnerabilities. Currently there are almost 100 CNAs in the world, with 65 software vendors in the group. For the most part, vendors tend to use their CNA authority to classify vulnerabilities for their own in-house software. The Microsoft, Oracle, and Symantec CNAs will cover only Microsoft, Oracle, and Symantec flaws, respectively. Micro Focus International and Canonical will handle SUSE and Ubuntu issues, while Red Hat is responsible for all other Linux issues. In the past, Red Hat was once responsible for all open source CVEs, but now the roles are being shared with other open source-oriented organizations.
Of all the CNAs, just two organizations, MITRE and the Zero Day Initiative are tasked to classify flaws that fall outside the scope of the other CNAs. For the open source community, that left a pretty sharp bottleneck to get projects’ vulnerabilities classified. Red Hat could pick up the slack, but the sheer number of open source software flaws have made it very difficult to keep up with demand. Five years ago, Seifried explained, there were something like 1,000 vulnerabilities a year. Nowadays, that rate is up to 1,000 flaws a month.
The creation of researcher-class CNAs help stem the tide of CVE identification, but the deluge is still coming.
“If you had told me a long time ago we would be past 2000-5000 vulnerabilities/year, I would have cried,” Seifried related “Now, it’s ‘whatever’.”
Faced with the rush of discovered flaws, the Distributed Weakness Filing (DWF) Project was launched to help mitigate this firehose. “DWF is for the open source world because CVEs were not fast enough,” Seifried said.
Initially, the DWF began with the idea of getting open source project vulnerabilities classified faster through the use of more automation, which, Seifried explained, “did not work as hoped.”
Today, the plan is to push the process of CVE assignment as close to the vulnerability as possible, by federating the CNA creation process itself.
“The more people who can be CNAs, the better. They can assign vulnerabilities their own numbers, more like a multi-maintainer model,” Seifried said. By creating more CNAs who can properly assign CVEs, the problem becomes a lot more manageable from a numbers standpoint. But the DWF is more than just getting more CNAs out in the world. Seifried emphasized that it’s also about growing and connecting the whole security vulnerability ecosystem.
Improvements to the CVE system itself are going to be a part of the DWF’s future, as well.
Previously, metadata for CVE entries were contained in LaTeX files. Now, metadata is held in JSON format, which is machine-parseable, and can contain vendor-specific descriptions of the vulnerability if needed, instead of one single global description.
The importance of an effective CVE system cannot be underestimated. In the metaphor of an emergency leads to calling 911 in the U.S. which in turn leads to the arrival of the authorities, CVE assignment is very much like calling 911: identifying the problem clearly so the right help can be assigned to the problem.
Because now the scale is growing even more, Seifried warned.
“Right now, how many companies ship a Linux distribution?” he rhetorically asked. “Everyone on Docker.”
Such a wide proliferation of Linux means the impact of any vulnerability is that much greater. The stakes are too high in a world where so much commerce depends on electronic transactions and secure platforms.
“Today, a bank robbery only gets someone $2,000-3,000 in cash, for a high risk,” Seifried said. “But multiple ATM withdraws can get much more money for a lower risk. That’s where I want the security industry to be, reducing risk and closing avenues of attack, and keeping them closed.”