We are pleased to report that OSVDB has been provided three projects for 2008. We would like to thank everyone that applied and encourage students that were not selected to still consider getting involved with the project. We had quite a few great applications but were unable to accept any more due to our limited mentoring resources this summer and the large number of new organizations taking part in SoC this year.
Here are the projects that were selected:
Patch Management Portal by Ronny Yabar Aizcorbe, mentored by David Shettler The system will provide a way to define when a patch should be in development, testing or production status. And will allow users the ability to select vulnerabilities and patches based on the OSVDB watch list. The main components of the tool will be: Prioritization and scheduling, Testing, Implementation and Compliance.
OSVDB Widgets and Gadgets by Marc Augustin, mentored by Chris Newby This project is intended to utilize the OSVDB as the main data source but should be a security dashboard for professionals via Gadgets and Widgets.
OSVDB Training Portal Framework by Sergios Pericleous, mentored by Jake Kouns This project will create a training framework which will aim to integrate as much as possible with the existing OSVDB portal. The portal will allow specific admin users to create training material and quizzes for end-users, and it will also allow end-users to read this training material and make comments on it, take the quizzes and receive a score, and to track their progress using a progress report and graphs.
Congrats Ronny, Marc and Sergios and we look forward to another successful summer!
Dave pushed a new set of code changes today! Here is a very brief summary of some of the highlights:
- Browse now has: Browse by Top Creditee, Browse by Creditee Name [Remember, we need more entries at 100% to make this more accurate and complete. Mangle your own vulnerabilities and fill in the missing creditee!]
- Three new dates added to schema (Screenshot) [The new date fields won’t appear on the front end yet, as more changes are required, but we now have the capability to track a more thorough history of the vulnerability]
- Menu Changes and new pages in support of that.
- More diverse “Donation” options [Come on, donate 5 bucks and skip that fourth Latte!]
- General bug fixes/tweaks
- Vendor dictionary – change e-mail addresses to stop automatic harvesting
- New template for CSRF vulnerabilities
Behind the Scenes:
Today just happened to be the right day where I saw the Jekyll and “Hide” of Sun though. A few days ago, |)ruid posted about a Solaris ypupdated vulnerability in which he says it corresponds to CVE-1999-0208 / OSVDB 11517. Given the original vulnerability was published in 1994, I had doubts it was truly the same vulnerability. I replied asking for confirmation, |)ruid replied and CC’d the Sun Security Coordination Team. Within 24 hours, Sun replied with a detailed analysis explaining how 11517 was different from the newly created OSVDB 43433, but very much related. This mail is a VDB maintainer’s wet dream; if only every vendor would provide this kind of detail when there is confusion over published vulnerability information. This is clearly the Dr. Jekyll locked up in a Sun complex somewhere who deserves kudos for the reply.
The Sun Microsystems “SunSolve” database is a quagmire of technical muck that is only rivaled by the IBM APAR database I believe. Tonight I find myself plowing through a grotesque changelog of Sun Java System Directory Server (SJSDS?). Sun apparently hasn’t fully mastered the idea of hyperlinking to make those annoying numbers on the left lead to somewhere with more information. So I log into the SunSolve database using my super secret ID associated with a sizable company that owns lots of Sun products. I type in a few numbers of interest off that list and away I … don’t go. Mr. Hide stops me quick, telling me that to read the bug IDs I have to be a better customer apparently.
You have selected content which is only available to registered SunSolve users with a valid Sun Service Plan. Please Login to access the restricted content of SunSolve and the Sun System Handbook if you are logged in to SunSolve and have received this message, please verify that you are associated with a valid support contract in the iSupport tool. If you have any questions about your support contract, please follow up with the Sun contract administrator contact at your company. If, however, none of the previous conditions apply, you may be trying to access a document that is no longer available. In this case please feel free to click on the SunSolve Feedback link at the bottom of the page and be sure to include the exact steps you took before you received this error message.
Wow, way to foil me via security through obscurity Sun Microsystems. Please take Mr. Hide and shove my beer bottle up his ass, sideways. Booze is the only way to adequately cope with the kind of headache born from vendors who can’t manage, organize and share information.
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.