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.
Really IBM, the amount of information common to all three pages is overwhelming. Do you really need a new APAR number issued for component name or level? Can’t you just list them all in one APAR and save us time? More importantly, do we need three APAR entries that say “a security issue has been fixed” and make us dig up the information?
A while back, Microsoft announced they were moving to release patches on the second Tuesday of each month, lovingly called Patch Tuesday. Soon after, Oracle announced that they too would be moving to scheduled releases of patches on the Tuesday closest to the 15th day of January, April, July and October. Now, Cisco has announced they are moving to scheduled patches on the fourth Wednesday of the month in March and September of each calendar year.
In the attempt to make life easier on administrators and help avoid installing patches every few days, these scheduled releases are now causing organizations to enjoy life between monster patches.
Mar 11 – Microsoft
Mar 26 – Cisco
Apr 8 – Microsoft
Apr 15 – Oracle
May 13 – Microsoft
June 10 – Microsoft
July 8 – Microsoft
July 15 – Oracle
August 12 – Microsoft
September 9 – Microsoft
September 24 – Cisco
October 14 – Microsoft, Oracle
November 11 – Microsoft
December 9 – Microsoft
As you can see, October 14 promises to be a lot of fun for companies running Oracle products on Microsoft systems. While the scheduled dates look safe, I can’t wait until we see the ”perfect storm” of vendor patches.
In a recent discussion on the security metrics mailing list, Pete Lindstrom put forth a rough formula to throw out a number of vulnerabilities that have been discovered versus undiscovered. One of the data points that he cited lead me to his page on “undercover vulnerabilities”, his term for “0-day” in a certain context. Since the term “0-day” has been perverted to mean many things, he clearly defines his term as:
Undercover Vulnerability: A vulnerability that was generally unknown (e.g. not published on any lists, not discussed by “above ground” security folks) until it was actively exploited in the wild. The vulnerability was discovered through evidence of tampering or other means, not through the usual bugfinding ritual.
In my reply challenging some of his numbers, I specifically said that “if we consider that your number 20 is off by at least half, and I would personally guess it’s more like a small fraction, how does this change your numbers?” Pete took this in stride and offered to buy me a case of beer if I could find half a dozen that he didn’t have. Not one to pass up free booze and vulnerability research (yes, i’m weird) I spent several hours Friday doing just that. I ended up with 24 vulnerabilities that seemed to match his definition, roughly half of them in his time frame (“in the last two years”).
Pete’s page got me wondering just how many vulnerabilities classified as ‘undercover’ by his definition. Further, I thought about another question he asked on his page:
I am open to suggestions on an easy way to do this with TypePad (TypeLists, maybe?). Else, I’ll just periodically update as new vulns become available.
I cornered our lead developer Dave and said “make it so” while I mailed Pete asking if OSVDB could help in this effort. As a result, we now have a new classification that we call “Discovered In the Wild” that means the same thing as Pete’s “undercover vulnerability”. I have updated the 20 vulnerabilities listed on his page and added the flag to the ones I researched. This now shows 43 results which is good progress.
Not content with that, I asked a fellow geek who has a world more experience with IDS, NOC management and various devices that would be prone to catching such vulnerabilities “how many do you think were found this way last year”, to which she replied “at least 50”. So vulnerability researchers and OSVDB contributors, it’s up to you to help out! We’re looking for more instances of vulnerabilities being discovered “in the wild”, being exploited and subsequently disclosed (to mail list, vendor, whatever). Please cite your source as best as possible.
To see what we have so far:
- Under “Vulnerability Classification” and “Disclosure”
- Check “Discovered in the Wild”
Thanks to Pete Lindstrom and the Security Metrics mailing list for the input and great idea for a new classification!
Early in 2006, I posted about HP using multiple identifiers for the same vulnerability. Recently, Sun Microsystems has done a little overhaul to their advisory pages and I noticed that they too now use entirely too many tracking numbers.
For example, this Sun advisory has the following:
- Document ID: 200582
- Old Document ID: (formerly 103143)
- Bug ID: 6497289
- SA Document Body: PPGNRLA Internal ID use only.
Why is one tracking number so difficult?
Nutshell What you see here is the output of the ”arfis project”, a simple perl script. It automatically downloads and extract PHP projects from sourceforge.net and checks for Remote File Inclusion vulnerabilities. It then post’s the potential (now it’s -potential-, cause the script is in an early stadium) vuln to this blog.
The idea behind this tool was joked about by several VDB managers over a year ago due to the growing trend of false vulnerability reports popping up in 2006 and 2007. The style of many posts to mail lists were becoming the same, several signatures suggesting a tool or group was involved appeared and it was speculated that many remote file inclusion (RFI) vulnerabilities were the result of a very primitive “grep and gripe” style vulnerability ‘research’. Jump to today and we have this script doing what we suspected all along. Some will proclaim “genious!” and others may be quick to download and taste the fame of being a “vulnerability researcher”. Before you plan your victory party and brush up your resume to include vulnerability research, consider that this script is blindly searching projects for specific lines that suggest an application is vulnerable to RFI. Without looking at the source code manually, there is no way to accurately determine if it is a legitimate vulnerability or a false positive. The people using this script don’t seem to fully understand that and blindly use the tool w/o consideration.
Recently, 8 or so of these arfis-found vulnerabilities were reported to milw0rm for inclusion in their database. Upon examination, 6 of the 8 were not legitimate vulnerabilities. Of the 2 that were, one had been reported two years prior. This is a good indication of how trustworthy the tool is, early release or not, and what kind of burden it places on VDBs who do their best to vet vulnerability disclosures to a limited degree.
Yes yes, yet another “Month of..” campaign. If you track the mail lists, you may have seen a post about a “Month of [something]” Bugs. Despite little follow-up, this campaign is going strong on the 17th day demonstrating a variety of vulnerabilities in lycos.com, search.myway.com, images.google.com, mamma.com, metacrawler.com, ezilon.com, ask.com, ftpsearch.rambler.ru, searcheurope.com, blogs.yandex.ru, clusty.com, autos.msn.com, shopping.msn.com, gigablast.com, hotbot.com, search.yahoo.com and meta.ua.
Definitely an interesting project to follow.
A while back I wrote about VDBs and site specific vulnerabilities. The general concensus is that VDBs should not track site specific vulnerabilities, even though some do for bigger sites that provide services (i.e. Google, Gmail, Yahoo). While OSVDB does not, we recently ran across a site that is now tracking Cross-Site Scripting (XSS) vulnerabilities in web sites. Interesting watching various high profile sites that don’t appear to properly test their applications before deployment.
It was bound to happen, now we get to see a Month of Search Engine Bugs. It would be nice if this effort included some bugs with meat rather than relatively obscure cross-site scripting issues.
The time has come for announcement of my new project – Month of Search Engines Bugs. This project will be in the next month. So June is a month of bugs in search engines. Purpose of this Month of Bugs is a demonstration of real state with security in search engines, which are the most popular sites in Internet. To let users of search engines and web community as a whole to understand all risks, which search engines bring to them. And also to draw attention of search engines~R owners to security issues of their sites. During the month everyday will be publish vulnerabilities in most popular search engines of the world. Cross-Site Scripting vulnerabilities in particular. Everyday will be publish vulnerabilities in different engines (minimum one publication at a time, but there will be bonus publications also).