Like any circle in any industry, having good professional relationships can be valuable to involved parties. In the world of security, more specifically Vulnerability Databases (VDBs), the relationships we maintain benefit the community behind the scenes. Like ogres and onions, there are layers.
Someone from CVE and someone from OSVDB run an informal list called ‘Vulnerability Information Managers’ (VIM) for discussion of vulnerabilities as relates to post-disclosure issues. New information comes up, additional research, vendor confirmations, vendor disputes and more. It’s a great resource for us to discuss the details that help each VDB fine-tune their information. (No new vulnerabilities are posted there, don’t bother)
In addition, some of the VDBs have stronger relationships that allow for great dialogue and information sharing. A few examples of these, from OSVDB’s perspective:
- A couple of the CVE guys are great for very informal chat about vulnerabilities. Despite being the dreaded “government contractors”, they are respectable, very knowledgeable and have a great sense of humor. I just sent one a mail with the subject “PROVENANCE BITCHEZ?!” challenging him on the details of a given CVE. They are so nice, I broke my rule of not taking candy from strangers and happily accepted the bag of leftover candy from their BlackHat booth. Joking aside, the ability to coordinate and share information is incredible and a testament to their integrity and desire to help the industry.
- OSVDB uses Secunia for one of our feeds to gather information. The two guys we regularly have contact with (CE & TK) lead a bright team that does an incredible amount of work behind the scenes. In case it slipped your attention, Secunia actually validates vulnerabilities before posting them. That means they take the time to install, configure and test a wide range of software based on the word of 3l1t3hax0ry0 that slapped some script tag in software you never heard of, as well as testing enterprise-level software that costs more than OSVDB makes in five years. Behind the scenes, Secunia shares information as they can with others, and there is a good chance you will never see it. If you aren’t subscribed to their service as a business, you should be. For those who asked OSVDB for years to have a ‘vulnerability alerting’ service; you can blame Secunia for us not doing it. They do it a lot better than we could ever hope to.
- The head of R&D at Tenable contributes a lot of time and information to VIM based on his research of disclosed vulnerabilities. Installing the software, configuring, testing and sometimes noticing additional vulnerabilities. He is a frequent contributor to VIM and has worked with OSVDB on sharing information to enhance the Nessus plugins as well as the OSVDB database.
- str0ke, that mysterious guy that somehow manages to run milw0rm in his spare time. What may appear to some as a website with user-posted content, is actually a horrible burden to maintain. Since the site’s inception, str0ke has not just posted the exploits sent in, but he has taken time to sanity check every single one as best he can. What you don’t see on that site are dozens (hundreds?) of exploits a month that were sent in but ended up being incorrect (or as OSVDB would label, “myth/fake”). When str0ke was overwhelmed and decided to give up the project, user demand (read: whining & complaints) lead him to change his mind and keep it going. Make sure you thank him every so often for his work and know this: milw0rm cannot be replaced as easily as you think. Not to the quality that we have seen from str0ke.
Since we have no corporate overlords, I’ll go ahead and talk about the flip side briefly:
- ISS (now IBM) runs a good database. Very thorough, keen to detail on including original source and vendor information. In 2004, the head of that group (AF) left, and until that time, we had a great dialogue and open communication. Since then, even before the IBM frenzy, we’ve mostly gotten the cold shoulder when mailing. Even when pointing out problems or negative changes on their side. LJ, bring back the old days!
- NVD. Why do you waste taxpayer money with that ‘database’? We pay $22 for Booz Allen Hamilton to “analyze” each CVE entry (thanks FOIA request!), yet they find a fraction of the typos and mistakes I do? By fraction, I mean exactly none from what I hear through the grape vine (DHS cronies are cool). If you can’t notice and report simple typos in a CVE, and you botch CVSS2 scores left and right (yes, I’ve mailed in corrections that were acted on), what exactly are you doing with our money? Are you the virtual Blackwater of VDBs?
- SecurityFocus / BID. Sorry, not going to bother with verbal fluffing. My countless mails pointing out errors and issues with your database are seemingly dumped to a black hole. Your promises of certain mail archives ‘not changing’ were pure fantasy. To this date you make erroneous assumptions about affected products, and still don’t grasp “case sensitive”. I know some of your team, you have great people there. Just lift the corporate policy that turns them into virtual shut-ins, please?
Sorry to end it on a downer. I still dream of a niche of the security industry (VDBs) where we can all play well with each other.
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.
Another night of working on OSVDB, mainly focusing on vulnerability import and creating our entries to cover issues. Most nights end with between 25 and 50 new entries and a feeling of accomplishment. Well, other manglers can see the accomplishment if they check the back end, and that gives a little positive reinforcement. On really big days I just spam the status line to Jake and Sullo and demand instant gratification and the promise of booze to dull the pain.
Anyway, tonight was productive but no one but me and Speedbump will realize. I can thank IBM and a set of ridiculously large changelogs full of mind-numbing poorly written bug reports and excessive (apparent) duplication of entries. It started out with a simple bugtraq post about some vulnerabilities in IBM WebSphere Application Server. First off, I find it quite amusing that people are now taking credit for merely posting vulnerability information culled from another source.
Provided and/or discovered by:
Reported by the vendor
Reported by SnoB
If this type of activity deserved merit, VDBs like Secunia, CVE and OSVDB would be virtual gods of vulnerability disclosure. Second, he lists seven issues from a changelog that contains hundreds. If you go dig through the changelogs like the one for the Fix List for WebSphere Application Server Version 5.1.1, you may find more of interest. While browsing them, I noticed a fairly insignificant but ironic characteristic of the way IBM handles these disclosures. If you want to read the list of over five hundred entries and only pick out the security related ones, you can! Skim the list for any P##### number that doesn’t hyper-link to another document. 95% of the time, these are security related. So while IBM is not providing additional details about these issues (security through obscurity), they are making it easier to pick out which entries are of interest.
Oh yes, back to the exciting night life. After checking the latest list of changes as well as digging into some past fix lists, I ended up with around 75 more vulnerabilities, most of which are not in our database (or others). This list I extracted has some dupes in it, meaning the same issue affected multiple products or version lines. However, it is quite curious to see the same vulnerability patched half a dozen times over two years across many versions. Is IBM reintroducing the same vulnerability back into the code over and over? Or are they following the Oracle method of mitigation and not looking at the bigger picture and fixing similar vulnerabilities in the same code? Anyway, since I know I won’t get an answer to that, consider that it would take you twenty or more hours to read and digest a handful of these fix lists, and in doing so, you would likely find fifty or more vulnerabilities above and beyond what I found. The amount of information is overwhelming to say the least.
Something lead you to the product that ended up on your systems. Be it a feature, a look, ease of use, or price, it was a driving force in your decision. Changing to a different product isn’t easily done, especially if your current solution is heavily integrated or customers/users are familiar with it. Besides, what other product can fill your needs that doesn’t have vulnerabilities of it’s own? Look at the amount of vulnerabilities released along with the diversity of the products. Whether it is no name freebies or million dollar commercial installations, every package seems to have vulnerabilities that would drive you back to where you started.
Offering a “solution” of “Use another product” doesn’t seem very intuitive, logical, or helpful to customers.