The last few days I have looked at ways to track open security -issues here at the University of Oslo where I work. My idea was that -it should be possible to use the information in security issues +issues here at my work with the University of Oslo. My idea is that +it should be possible to use the information about security issues available on the Internet, and check our locally -maintained/distributed software against this information to verify -that no known security issue had been forgotten. The CVE database -listing vulnerabilities seem like a great central point, and by using -the package lists from Debian mapped to CVEs provided by the testing -security team, it should be possible to figure out which security -holes were present in our free software collection.
+maintained/distributed software against this information. It should +allow us to verify that no known security issues are forgotten. The +CVE database listing vulnerabilities seem like a great central point, +and by using the package lists from Debian mapped to CVEs provided by +the testing security team, I believed it should be possible to figure +out which security holes were present in our free software +collection. -After reading up on the issue, it became obvious that the first +
After reading up on the topic, it became obvious that the first
building block is to be able to name software packages in a unique and
consistent way across data sources. I considered several ways to do
this, for example coming up with my own naming scheme like using URLs
-to project home pages or URLs to the Freshmeat entries. But it seem
-like I am not the first one to come across this problem, and MITRE had
-already proposed and implemented a solution to this naming problem.
-Enter the
To give you an example. The GNU gzip source package have the CPE +name cpe:/a:gnu:gzip. If the old version 1.3.3 was the package to +check out, one could look up +cpe:/a:gnu:gzip:1.3.3 +in NVD and get a list of 6 security holes with public CVE entries. +The most recent one is +CVE-2010-0001, +and at the bottom of the NVD page for this vulnerability the complete +list of affected versions is provided.
+The NVD database of CVEs is also available as a XML dump, allowing +for offline processing of issues. Using this dump, I've written a +small script taking a list of CPEs as input and list all CVEs +affecting the packages represented by these CPEs. One give it CPEs +with version numbers as specified above and get a list of open +security issues out.
- - CPE -> CVE +Of course for this approach to be useful, the quality of the NVD +information need to be high. For that to happen, I believe as many as +possible need to use and contribute to the NVD database. I notice +RHEL is providing +a +map from CVE to CPE, indicating that they are using the CPE +information. I'm not aware of Debian and Ubuntu doing the same.
+To get an idea about the quality for free software, I spent some +time making it possible to compare the CVE database from Debian with +the CVE database in NVD. The result look fairly good, but there are +some inconsistencies in NVD (same software package having several +CPEs), and some inaccuracies (NVD not mentioning buggy packages that +Debian believe are affected by a CVE). Hope to find time to improve +the quality of NVD, but that require being able to get in touch with +someone maintaining it. So far my three emails with questions and +corrections have not seen any reply, but I hope contact can be +established soon.
-http://web.nvd.nist.gov/view/vuln/search -http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-3430 -cpe:/a:kernel:linux-pam:1.1.2 +An interesting application for CPEs is cross platform package +mapping. It would be useful to know which packages in for example +RHEL, OpenSuSe and Mandriva are missing from Debian and Ubuntu, and +this would be trivial if all linux distributions provided CPE entries +for their packages.