CVE just announced reaching 30,000 identifiers which is a pretty scary thing. CVE staff have a good eye for catching vulnerabilities from sources away from the mainstream (e.g. bugtraq) and they have the advantage of being a very widely accepted standard for tracking vulnerabilities. As companies and researchers request CVE numbers for disclosures, they get a lot of the information handed to them on a silver platter. Of course, sometimes that platter is full of mud and confusion as vendors don’t always provide clear details to help CVE accurately track and distinguish between multiple vulnerabilities. I’ve also pointed out many times in the past that CVE is a very unique VDB that provides identifiers for vulnerability tracking. They do not provide many fields associated with other VDBs (solution, creditee, etc). As such, they may have a single entry that covers multiple distinct vulnerabilities if they are the same class (XSS, SQLi, RFI), or if there is a lack of details but they know it affects the same product (Oracle). So when we see 30,000 identifiers, we have to realize that the real count of vulnerabilities is significantly higher.
CVE is run by The MITRE Corporation, sponsored / funded by the NCSD (US-CERT) of DHS under government contract. That means our tax dollars fund this database so it should be of particular interest to U.S. taxpayers in the security industry. I know from past discussions with CVE staff and other industry veterans that on any given day, they are more likely to have more work than available staff. That means the rate of vulnerabilities that get published is greater than the resources CVE can maintain to track them. In short, the 30,000 identifiers you see only represents a percentage of the vulnerabilities actually disclosed. We could probably debate what percentage that represents all day long, and I don’t think that is really the point here other than “we know it isn’t all of them”.
Every VDB suffers from the same thing. “Commercial” VDBs like X-Force, BID and Secunia have a full time staff that maintain their databases, like CVE does. Despite having all of these teams (some of them consisting of 10 or more people) maintain VDBs, we still see countless vulnerabilities that are ‘missed’ by all of them. This is not a slight against them in any way; it is a simple manner of resources available and the amount of information out there. Even with a large team sorting disclosed vulnerabilities, some teams spend time validating the findings before adding them to the database (Secunia), which is an incredible benefit for their customers. There is also a long standing parasitic nature to VDBs, with each of them watching the others as best they can, to help ensure they are tracking all the vulnerabilities they can. For example, OSVDB keeps a close eye on Secunia and CVE specifically, and as time permits we look to X-Force, BID, SecurityTracker and others. Each VDB tends to have some researchers that exclusively disclose vulnerabilities directly to the VDB of their choice. So each one I mention above will get word of vulnerabilities that the rest really have no way of knowing about short of watching each other like this. This VDB inbreeding (I will explain the choice of word some other time) is an accepted practice and I have touched on this in the past (CanSecWest 2005).
Due to the inbreeding and OSVDB’s ability to watch other resources, it occasionally frees up our moderators to go looking for more vulnerability information that wasn’t published in the mainstream. This usually involves grueling crawls through vendor knowledge-bases, mind-numbing changelogs, searching CVS type repositories and more. That leads to the point of this lengthy post. In doing this research, we begin to see how many more vulnerabilities are out there in the software we use, that escapes the VDBs most of the time. Only now, after four years and getting an incredible developer to make many aspects of the OSVDB wish-list a reality, do we finally begin to see all of this. As I have whined about for those four years, VDBs need to evolve and move beyond this purely “mainstream reactionary” model. Meaning, we have to stop watching the half dozen usual spots for new vulnerability information, creating our entries, rinsing and repeating. There is a lot more information out there just waiting to be read and added.
In the past few weeks, largely due to the ability to free up time due to the VDB inbreeding mentioned above, we’ve been able to dig into a few products more thoroughly. These examples are not meant to pick on any product / VDB or imply anything other than what is said above. In fact, this type of research is only possible because the other VDBs are doing a good job tracking the mainstream sources, and because some vendors publish full changelogs and don’t try to hide security related fixes. Kudos to all of them.
Example: Search your favorite VDB for ”inspircd”, a popular multi-platform IRC daemon. Compare the results of BID, Secunia, X-Force, SecurityTracker, and http://osvdb.org/ref/blog/inspircd-cve.png. Compare these results to OSVDB after digging into their changelogs. Do these same searches for “xfce” (10 OSVDB, 5 max elsewhere), “safesquid” (6 OSVDB, 1 max elsewhere), “beehive forum” (27 OSVDB, 8 max elsewhere) and “jetty” (25 OSVDB, 12 max elsewhere). Let me emphasize, I did not specifically hand pick these examples to put down any VDB, these are some of the products we’ve investigated in the last few weeks.
The real point here is that no matter what vulnerability disclosure statistic you read, regardless of which VDB it uses (including OSVDB), consider that the real number of vulnerabilities disclosed is likely much higher than any of us know or have documented. As always, if you see vulnerabilities in a vendor KB or changelog, and can’t find it in your favorite VDB, let them know. We all maintain e-mail addresses for submissions and we all strive to be as complete as possible.
US Government Studies Open Source Quality reads the SlashDot thread, and it certainly sounds interesting. Reading deeper, it links to an article by the Reg titled Homeland Security report tracks down rogue open source code. The author of the article, Gavin Clarke, doesn’t link to the company who performed the study (Coverity) or the report itself. A quick Google search finds the Coverity home page. On the right hand side, under ‘Library’, there is a link titled NEW >> Open Source Quality Report. Clicking that, you are faced with “request information”, checking the “Open Source Quality Report” box (one of seven boxes including “Request Sales Call” as the first option, and “Linux Security Report” is the default checked box), and then filling out 14 fields of personal information, 10 of which are required.
So, let me get this straight. My tax dollars fund the Department of Homeland Security. The DHS opts to spend $1.24 million dollars on security research, by funding a university and two commercial companies. One of the commercial companies does research into open source software, and creates a report detailing their findings. To get a copy of this report, you must give the private/commercial company your first name, last name, company name, city, state, telephone, how you heard about them, email address, and a password for their site (you can optionally give them your title, and “describe your project”).
Excuse me, but it should be a CRIME for them to require that kind of personal information for a study that I helped fund via my tax dollars. Given this is a study of open source software, requiring registration and giving up that kind of personal information is doubly insulting. Coverity, you should be ashamed at using extortion to share information/research that should be free.
Even worse, your form does not accept RFC compliant e-mail addresses (RFC 822, RFC 2142 (section 4) and RFC 2821). Now I have to add your company to my “no plus” web page for not even understanding and following 24 year old RFC standards. HOW CAN WE TRUST ANYTHING YOU PUBLISH?!
Oh, if you don’t want to go through all of that hassle, you can grab a copy of the PDF report anyway.
Through its Science and Technology Directorate, the department has given $1.24 million in funding to Stanford University, Coverity and Symantec to hunt for security bugs in open-source software and to improve Coverity’s commercial tool for source code analysis, representatives for the three grant recipients told CNET News.com.
The Homeland Security Department grant will be paid over a three-year period, with $841,276 going to Stanford, $297,000 to Coverity and $100,000 to Symantec, according to San Francisco-based technology provider Coverity, which plans to announce the award publicly on Wednesday.
The project, while generally welcomed, has come in for some criticism from the open-source community. The bug database should help make open-source software more secure, but in a roundabout way, said Ben Laurie, a director of the Apache Foundation who is also involved with OpenSSL. A more direct way would be to provide the code analysis tools to the open-source developers themselves, he said.
So DHS uses $1.24 million dollars to fund a university and two commercial companies. The money will be used to develop source code auditing tools that will remain private. Coverity and Symantec will use the software on open-source software (which is good), but is arguably a huge PR move to help grease the wheels of the money flow. Coverity and Symantec will also be able to use these tools for their customers, which will pay them money for this service.
Why exactly do my tax dollars pay for the commercial development of tools that are not released to the public? As Ben Laurie states, why can’t he get a copy of these tax payer funded tools to run on the code his team develops? Why must they submit their code to a commercial third party for review to get any value from this software?
Given the date of this announcement, coupled with the announcement of Stanford’s PHP-CHECKER makes me wonder when the funds started rolling. There are obviously questions to be answered regarding Stanford’s project (that I already asked). This also makes me wonder what legal and ethical questions should be asked about tax dollars being spent by the DHS, for a university to fund the development of a security tool that could potentially do great good if released for all to use.
It’s too bad there is more than a year long wait for FOIA requests made to the DHS.