Monthly Archives: August, 2009

Mangle-A-Thon Boston

Mangle-A-Thon Boston
by D2D


Join OSF in Somerville, MA on September 19th, 2009 from 8am to midnight for Mangle-A-Thon, and help us mangle vulnerabilities into the Open Source Vulnerability Database (OSVDB), and mangle data loss incidents and primary sources into the DataLossDB.

The event, hosted by Midnight Research Labs Boston, is free and sponsored by Voltage Security, which will assist us in providing food and drink for attendees. OSF moderators will walk participants through the projects and teach participants how volunteers maintain the entirety of both data sets. Our goal is to get as much new and accurate data into both databases as possible, possibly add a couple of new recruits into the fold, and have a good time doing it.

Have suggestions regarding the projects? The lead developer (Dave) will be there, as will lead content guys for both projects (Kelly and Craig). You can actually see your suggestions implemented right there at the event… but only if you attend. 🙂


Midnight Research Labs Boston
30 Dane Street
Somerville, MA


Saturday, September 19th, 2009
8am to midnight
(three time slots: 8am – 1pm, 1pm – 6pm, 6pm – midnight, register for all or some)

Register via the “Register” link at:

Reviewing(4) CVE

As I was working on OSVDB tonight I spent some time on the CVE website. I decided to quickly review the current list of CVE-Compatible Products and Services ( and noticed that OSVDB was not on the list. I was pretty confused as I thought we should have been given that we submitted the paperwork many years ago. When we first submitted the only requirement that we were not able to meet was showing the difference of CAN or CVE based on the status of the entry. We thought this was quite silly as it didn’t appear to be used much and historically entries that met criteria would stay in CAN status for years. This lead us to send mail to the CVE staff asking about the designations and if they still thought it practical. The responses we recieved were informative and reasonable, but they expressed doubt on if it still had value and if they would continue to distinguish. We indicated that was a good call, and that we would not change OSVDB to accommodate that distinction as we saw no value in it under the current CVE. A few months later, CVE announced that they were no longer supporting CAN vs CVE and that moving forward, all new entries would be CVE. I figured OSVDB was good to go for compatibility at that point… but apparently not. After some more digging I then found that we were only listed on the Declarations to Be CVE-Compatible page ( Obviously we have missed something and hope to get it corrected in short order, and certainly hope it won’t involve more paperwork.

Speaking of voting, if you look at a CVE entry there are a couple things that stand out as a bit odd considering CVE dropped support for the CAN status. There are several fields such as Status, Phase and Voting that no longer affect or improve the information made available by CVE. For example, if you look at most of the recent CVE entries you see something such as the following:

Candidate This CVE Identifier has "Candidate" status and must be reviewed and accepted by the CVE Editorial Board before it can be updated to official "Entry" status on the CVE List. It may be modified or even rejected in the future.
Assigned (20090602)

If you go back further in time and check out an early CVE entry, for example the CVE referenced in OSVDB 1 (ColdFusion Application Server exprcalc.cfm OpenFilePath Variable Arbitrary File Disclosure), you will see something a bit different. The same fields are present but there is additional information and comments populated in those same fields. Take a look at CVE-2004-0230:

Candidate This CVE Identifier has "Candidate" status and must be reviewed and accepted by the CVE Editorial Board before it can be updated to official "Entry" status on the CVE List. It may be modified or even rejected in the future.
Modified (19991210-01)
ACCEPT(3) Frech, Ozancin, Balinsky
MODIFY(1) Wall
NOOP(1) Baker
REVIEWING(1) Christey
Wall> The reference should be ASB99-01 (Expression Evaluator Security Issues)
make application plural since there are three sample applications
(openfile.cfm, displayopenedfile.cfm, and exprcalc.cfm).
Christey> The CD:SF-EXEC and CD:SF-LOC content decisions apply here.
Since there are 3 separate "executables" with the same
(or similar) problem, we need to make sure that CD:SF-EXEC
determines what to do here. There is evidence that some
of these .cfm scripts have an "include" file, and if so,
then CD:SF-LOC says that we shouldn’t make separate entries
for each of these scripts. On the other hand, the initial
L0pht discovery didn’t include all 3 of these scripts, and
as far as I can tell, Allaire had patched the first problem
before the others were discovered. So, CD:DISCOVERY-DATE
may argue that we should split these because the problems
were discovered and patched at different times.

In any case, this candidate can not be accepted until the
Editorial Board has accepted the CD:SF-EXEC, CD:SF-LOC,
and CD:DISCOVERY-DATE content decisions.

You can see that it is still a candidate, but it is in a modified phase and there are some comments that provide additional insight into what the CVE guys are thinking on this vulnerability. Now to my favorite part, the voting. You can see that there are actually some votes on this one! There are 3 ACCEPT, 1 MODIFY, 1 NOOP and 1 REVIEWING. I love the fact that Christey is still reviewing this entry. You have to hand it to him he is very thorough in his work.. I knew he was passionate but to invest close to 10 years reviewing this entry is some real dedication! Perhaps he wants to REJECT but is waiting until his vote can be the deciding factor? =)

Other “legacy” entries can be found in CVE that do not meet their current standards. For example, CVE-1999-0651 (and a couple dozen like it) cover a particular service running. This is actually somewhat of a precursor to what became CWE:



(under review)
• Severity Rating • Fix Information • Vulnerable Software Versions • SCAP Mappings
The rsh/rlogin service is running.
Note: References are provided for the convenience of the reader to help distinguish between vulnerabilities. The list is not intended to be complete.
Candidate This CVE Identifier has "Candidate" status and must be reviewed and accepted by the CVE Editorial Board before it can be updated to official "Entry" status on the CVE List. It may be modified or even rejected in the future.
Proposed (19990804)
ACCEPT(2) Wall, Baker
MODIFY(1) Frech
NOOP(1) Christey
REJECT(1) Northcutt
Christey> aka "shell" on UNIX systems (at least Solaris) in the
/etc/inetd.conf file.
Frech> associated to:

Candidate assigned on 19990607 and proposed on 19990804

Even that far back, other databases (notably ISS X-Force) were doing the same. In the case of X-Force, those mappings had a more logical place given their database supported a vulnerability scanner. A year or two ago, out of curiosity, OSVDB formally requested a legacy entry like this one be retired as it no longer met standards for inclusion in CVE. As far as we know, the request is still being reviewed =)

In all seriousness, the guys at CVE are great folks and provide a much-needed service in the security industry. We have gotten to know many of them and work very closely with them regarding vulnerabilities, disclosure and related topics. We really have nothing but nice things to say about them despite the occasional joke we throw out there from time to time! Further, I know when OSVDB started there were a lot of things that seemed like the “right” thing to do… or the “right” way to do it. But the reality was and still is that the sheer volume of vulnerabilties that must be processed is enormous. The amount of time it takes just to figure out what is going on is hard enough to keep up with whether you have a paid staff or are a volunteer organization like OSVDB. We have tried to stay true to our roots but have had to make several changes to processes and standards over time to evolve. As we have been preaching for some time, VDBs need to keep evolving to better serve the industry. While it may be painful at first, it frequently leads to a more streamlined process that saves time and headache for years to come. Perhaps it is time for even our friends over at CVE to take a look at their processes and figure out what makes sense to continue and what should be retired.

Any votes?

ACCEPT(2) Jkouns, Jericho
NOOP(2) Dave, Lyger

VDB Relationships (hugs and bugs!)

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.