Category Archives: Vulnerability Databases

MITRE’ Horrible New CVE ID Scheme and Spindoctoring

Today, The Register wrote an article on MITRE’s announcement of a new CVE ID scheme, and got many things wrong about the situation. As I began to write out the errata in an email, someone asked that I make it public so they could learn from the response as well.


From The Register:

The pilot platform will implement a new structure for issuance of Common Vulnerabilities and Exposures numbers. MITRE will directly issue the identifiers and bypass its editorial board.

The old system bypassed the Editorial Board. The Board isn’t there to give input on assignments, not for over 10 years. The criticism right now is that the new system was rolled out without consulting the Board, which the board is supposedly there for:

The MITRE Corporation created the CVE Editorial Board, moderates Board discussions, and provides guidance throughout the process to ensure that CVE serves the public interest.

The last ID scheme change was after more than a year of discussion, debate, and ultimately a vote by the board (11/2/2012 Start –> 6/7/2013 End). This ID scheme change was a knee-jerk response to recent criticism (only after it became more public than the Editorial Board list), without any board member input. From The Register article:

The CVE numbers are the numerical tags assigned to legitimate verified bugs that act as a single source of truth for security companies and engineers as they seek to describe and patch problems.

No… CVE IDs are assigned to security issues, period. Alleged, undetermined, possible, or validated. Many IDs are assigned to bogus / illegitimate issues, which are generally discovered after the assignment has been made. There is no rule or expectation that IDs are only assigned to legitimate verified bugs. To wit, search the CVE database for the word “REJECTED”.

More importantly, the notion it is a “single source of truth” is perhaps the worst characterization of CVE one could imagine. Many companies use alternate vulnerability databases that offer more features, better consumption methods, and/or much better coverage. With MITRE falling behind other VDBs by as many as 6,000 vulnerabilities in 2015 alone, it isn’t a single source for anything more than training wheels for your vulnerability program.

The platform will exist alongside the current slower but established CVE system.

At this point, with what has been published by MITRE, this is pure propoganda in line with the platitudes they have been giving the Editorial Board for the last year. The new format does not make things easier for them, in any way. The ‘old ID scheme’ was never the slowdown or choke point in their process. In fact, read their press release and they say they will be the only ones issuing federated IDs, meaning the same problem will happen in the interim. If it doesn’t, and they start issuing faster, it wasn’t the new scheme that fixed it. More important to this part of the story is that it wasn’t just about assignment speed. The last six months have seen MITRE flat out refuse assignments to more and more researchers, citing the vulnerable software isn’t on their list of monitored products. Worse, they actually blame the Editorial Board to a degree, which is a blatant and pathetic attempt at scape-goating. The list they refer to was voted on by the board, yes. But the list given to the board was tragically small and it was about arranging the last chairs on the Titanic so to speak.

He says MITRE is aiming for automated vulnerability identification, description, and processing, and welcomed input from board members and the security community.

This is amusing, disgusting, and absurd. MITRE, including the new person in the mix (Sain) have NOT truly welcomed input from the board. The board has been giving input, non-stop, and MITRE has been ignoring it every single time. Only after repeated mails asking for an update, do they give us the next brief platitude. Sain’s title, “MITRE CVE communications and adoption lead”, is also ironic, given that just last week Sain told the board he would contact them via telephone to discuss the issues facing CVE, and never did. Instead, there was no communication, and MITRE decided to roll out a scheme that was horribly designed without any input from the Board or the industry.

For those who want a better glimpse into just how bad MITRE is handling the CVE project, I encourage you to read the Editorial Board traffic (and hope it is updated, as MITRE still manually runs a script to update that archive).

Ruminations on David Weinstein’s “Ruminations on App CVEs”

David Weinstein, a researcher at NowSecure, has posted a blog titled “Ruminations on App CVEs“. Thanks to Will Dormann’s Tweet it came to our attention, and he is correct! We have opinions on this. Quoted material below is from Weinstein’s blog unless otherwise attributed.

CVE is well-positioned to play a critical role in tracking the risk level of mobile computing.

This is trivially to debate and counter in 2015. Until last year, CVE maintained a public list of sources that was virtually unchanged since its inception in 1999. After pressure from the public and the CVE Editorial Board, compromised of non-MITRE industry “advisors”, CVE revised their coverage policy and shifted to a new system of ‘full’ or ‘partial’ coverage based on the vendor, product, and/or vulnerability source. On the surface, this list looks promising, but upon any significant scrutiny, it is utterly lacking in adequate coverage. In order to head off complaints, their webpage even qualifies ‘full coverage’ sources by using the phrasing “nearly all issues disclosed” to “allow the flexibility to potentially postpone coverage of minor issues”.

In fact, Steve Christey may disagree with your assertion. In 2013, he posted to the VIM list saying:

Unfortunately, CVE can no longer guarantee full coverage of all public vulnerabilities… we are not well-prepared to handle the full volume of CVEs for all publicly-disclosed vulnerabilities… – Steve Christey, Editor of CVE

Given the 39,280 vulnerabilities we track that do not have a CVE assignment, assignment volume is specifically a problem for them. Further, the current state of CVE assignments is a disaster, and I have been in mails with CVE staff actively encouraging them to figure out the problem, as my now 27 day wait for three different CVE assignments is getting ridiculous.

However, CVEs have largely focused on tracking server-side and related flaws and yet the security community has evolved to track client-side vulnerabilities as a critical aspect of dealing with risk.

While I can’t offer you a set of handy statistics to back this claim, know that CVE, or their CNAs, assign identifiers to a considerable number of client applications. In fact, with the release of Apple iOS 9 yesterday, the public learned of 91 _new_ vulnerabilities affecting the platform, many of them client-side. I do not believe this statement to be a fair criticism of CVE’s assignment history and policy.

While CVE has worked well for tracking system flaws in mobile operating systems, there remain quirks with regard to mobile app flaws.

There are around 90 vulnerabilities in Google Android alone, that do not have CVE assignments, and that represents a fairly significant percentage overall. However, in this case we can’t blame CVE at all for this shortcoming, as the fault lies entirely with Google instead.

It seems like using CVE is the “right thing” here but MITRE has been very cryptic (in my opinion) about what qualifies as something that gets a CVE and what doesn’t. These discussions should not happen in some closed door meeting in my opinion, or at least should not end there…

First, please factor in that CVE and every other vulnerability database has gone through a world of headache, dealing with researchers who do not fully understand the concept of ‘crossing privilege boundaries’. The number of “not-a-vuln” vulnerability reports we see has skyrocketed this year. Further, even from individuals that are very technical, don’t always convey their information in terms that are easily understood. They clearly see a vulnerability, the report they send doesn’t show it to our eyes. It requires back-and-forth to figure it out and better understand the exact vulnerability. Bottom line, some are clear-cut cases and typically get a quick assignment. Other cases are murky at best.

Second, I fully agree that such a discussion should not be behind closed doors. At the very least, it should include the CVE editorial board, and ideally should include anyone in the industry who has an interest in it. If you want to bring up the discussion on the VIM mail list, which has over one hundred members, including at least one person from each of the major public vulnerability databases, please do.

Is MITRE consistently responding to other researchers’ requests for CVEs?

No. The turnaround time for requesting a CVE has gone up considerably. As mentioned above, I have been waiting for three assignments for almost one month now, while CVE assigned two others filed on the same day within hours. They are not currently consistent with the same researcher, even one familiar with CVE and their abstraction and assignment policy.

Attaching a CVE to a vulnerable app, even if it’s an old version, is actually a big part of tracking the reputation of the developer as well!

Just quoting to signal-boost this, as it is a very important comment, and absolutely true.

Who acts as a certified numbering authority (CNA) on behalf of all the app developers on the market?

Based on the current list of CNAs, there is no CNA that covers third-party apps really, regardless of platform. Also note that many CNAs are not currently fulfilling their duties properly, and I have been trying to address this with MITRE for months. There is no current policy on filing a complaint against a CNA, there is no method for warning or revoking CNA status, and MITRE has dropped the ball replying to me on several different threads on this topic.

Should Google step in here as a formal body to assist with coordinating CVEs etc for these apps?

Absolutely not. While they are positioned to be the ideal CNA, their history in CVE assignments has been dismal. Further, they have so many diverse products, each with their own mechanism for bug reporting (if one exists), own disclosure policy (if one exists), and disclosure method (which doesn’t exist for many). We can’t rely on Google to disclose the vulnerabilities, let alone act as a CNA for standardized and formalized ID assignment. Could Google fix this? Absolutely. They are obviously overflowing with brilliant individuals. However, this would require a central security body in the company that crosses all departments, and fulfills such a duty. Due to the volume of software and vulnerabilities they deal with, it would require a small team. The same kind that IBM, Cisco, and other large companies already stand up and have used for years.

Is the process MITRE established designed and prepared to handle the mountain of bugs that will be thrown at it when the community really focuses on this problem as we have?

No, as covered above. CVE is already backpedaling on coverage, and has been for a couple years. That does not give any level of comfort that they would be willing to, or even could handle such a workload.

Can the community better crowd source this effort with confirmation of vulnerability reporting in a more scalable and distributed manner that doesn’t place a single entity in a potentially critical path?

Possibly. However, in the context of mobile, Google is a better choice than crowd-sourcing via the community. The community largely doesn’t understand the standards and abstraction policy that helps define CVE and the value. Many CNAs do not either unfortunately, despite them being in the best position to handle such assignments. Moving to a model that relies on more trusted CNAs has merit, but it would also require better documentation and training from MITRE to ensure the CNA follows the standards.

Every vendor distributing an app on the Play Store should be required to provide a security related contact e.g., security@yourdomain.com

Except, statistically, I bet that not even half of them have a domain! The app stores are full of a wide variety of applications that are little more than a hobby of one person. They don’t get a web page or a formal anything. Given the raw number of apps, that is also a tall order. Maybe apps that enjoy a certain amount of success (via download count?) would then be subjected to such rules?

Google could be a little clearer about when security@android.com should be used for organized disclosure of bugs and consider taking a stronger position in the process.

Little clearer” is being more than generous. Remember, until a month or two ago, they had no formal place or process to make announcements of security updates. Disclosures related to Android have been all over the board and it is clear that Google has no process around it.

MITRE and/or whoever runs CVE these days should clarify what is appropriate for CVEs so that we know where we should be investing our efforts

Absolutely, and CVE’s documentation the last decade or more has not been properly updated. Having such documentation would also potentially cut down on their headache, as requests are made for issues clearly not a vulnerability. But newcomers to security research don’t have a well-written guide that explain it.

Should we pursue a decentralized CVE request process based on crowdsourcing and reputation?

I cannot begin to imagine what this would entail or what you have in mind. On the surface, won’t happen, won’t work.

Hopefully others in the industry chime in on this discussion, and again, I encourage you to take it to the CVE Editorial Board and the VIM list, to solicit feedback from more. I appreciate you bringing this topic up and getting it attention.

Mobile Devices and Exploit Vector Absurdity

The last few days has seen several vulnerabilities disclosed that include serious gaps in logic with regard to exploitation vectors. What is being called “remote” is not. What is being called “critical” is not. Here are a few examples to highlight the problem. We beg of you, please be rational when explaining vulnerabilities and exploit chaining. The biggest culprit in all of this is the “need for a user to install a malicious app” to then allow a vulnerability to be exploited. Think about it.

Number One

We start with an H-Online article titled “Critical vulnerability in Blackberry 10 OS“. First word, critical. In the world of vulnerabilities, critical means a CVSSv2 score of 10.0 which essentially allows for remote code execution without user interaction. Consider that standard and widely accepted designation, and read the article’s summary of what is required to exploit this vulnerability:

As well as needing Protect enabled, the user must still install a malicious app, which then compromises a Protect-component so that it can intercept a password reset. This password reset requires the user, or someone who knows the BlackBerry ID and password, to go to the web site of BlackBerry Protect and request the password. If the attacker manages that, then the Protect component, compromised by the earlier malicious app, can let the attacker know the new password for the device. If he has physical access to the device, he can now log on successfully as the actual user. Otherwise, the attacker can only access Wi-Fi file sharing if the actual user has activated it.

The only thing missing from this exploit chain are the proverbial chicken sacrifices at midnight on a full blue moon. Want to get the same result much easier? Find your victim and say “Wow, that is a slick new phone, can I see it?” Nine out of ten times, they unlock the phone and hand it to you. Less work, same result.

Number Two

There were a few disclosures out of Japan’s JVN system, run by JPCERT. Two examples, both the same fundamental vulnerability, are summarized below:

#1 – CVE-2013-3643 (NVD Entry) – JVN 99813183 / JVNDB-2013-000056
#2 – CVE-2013-3642 (NVD Entry) – JVN 79301570 / JVNDB-2013-000055

#1 – The Galapagos Browser application for Android does not properly implement the WebView class, which allows attackers to obtain sensitive information via a crafted application.

Despite all these references, users are left with either incorrect or very misleading information. First, CVE says “an attacker” instead of qualifying it as a local attacker. I only call them out because they are historically more precise than this. Second, NVD calls this a “context-dependent” attacker via the CVSSv2 score (AV:N/AC:M/Au:N/C:P/I:N/A:N), saying it can be exploited over the network with moderate user interaction. NVD also says this affects confidentiality ‘partially’. JVN goes so far to say it can be exploited “over the Internet using packets” with “anonymous or no authentication”.

The Reality

The reality of these vulnerabilities is that they are not remote. Not in any form under any circumstances that the vulnerability world accepts. For some reason, VDBs are starting to blur the lines of exploit traits when it comes to mobile devices. The thought process seems to be that if the user installs a malicious application, then the subsequent local vulnerability becomes ‘remote’. This is absurd. Just because that may be the most probable exploit vector and chaining, does not change the fact that getting a user to install a malicious application is a separate distinct vulnerability that cannot have any scoring weight or impact applied to the vulnerability in question. If you can get a phone user to install a malicious application, you can do a lot more than steal ‘partial’ information from the one vulnerable application.

Let me put it to you in terms that are easier to understand. If you have a Windows local privilege escalation vulnerability, it is local. Using the above logic, if I say that by tricking a user into installing a malicious application it can then be exploited remotely, what would you say? If you have a Linux Kernel local DoS, it too can become remote or context-dependent, if the root user installs a malicious application. You can already spin almost any of these local vulnerabilities into remote by saying “remote, authentication required” and assuming it can be done via RDP or SSH. To do so though, devaluates the entire purpose of vulnerability classification.

Any doubts? Consider that CVE treats the exact same situation as the mobile browser vulnerabilities above as a local issue in Windows, even when a “crafted application” is required (see IDs below). The only difference is if the local user writes the application (Windows), or gets the user to install the application (Mobile). Either way, that is a local issue.

CVE-2013-1334CVE-2012-1848CVE-2011-1282CVE-2010-3942CVE-2009-1123CVE-2008-2252

CVSSv2 Shortcomings, Faults, and Failures Formulation

The Open Security Foundation (OSF) and Risk Based Security wrote an open letter to FIRST regarding the upcoming Common Vulnerability Scoring System (CVSS) version 3 proposal. While we were not formally asked to provide input, given the expertise of managing vulnerability databases, along with the daily use of CVSS, we felt the feedback would provide valuable insight to improve CVSS in the future.

Some of the areas discussed include:

  • Introducing 4 levels for granularity
  • Better definitions for terminology for more accurate scoring
  • Re-examining the pitfalls of “Access Complexity”
  • Limitations of the current Access Vector breakdown
  • The challenge of scoring authentication
  • And a variety of other considerations to improve vulnerability scoring

Our conclusion points to the need for CVSS to be overhauled as CVSSv2 has too many current shortcomings to provide an adequate and useful risk scoring model. You can download the full letter in PDF format.

What I learned from early CVE entries!

This post is the farthest thing from picking on or insulting CVE. They were running a VDB some four years before OSVDB entered the picture. More impressive, they operated with a level of transparency that no other VDB offered at the time. Early OSVDB entries suffered just as greatly as the early CVE entries, and we even had the benefit of four years to learn from their efforts. Reading the original CVE entries is a fun look at how it all began. This post is a brief light-hearted look at the past.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-0345 – CVE contributors can be stumped

http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-0465 – Client side vulnerabilities aren’t an issue.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-0285 – No reference, no problem!

http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-0549 – ISS tried desperately to help.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=1999-0684 – A CVE entry can be a duplicate of itself.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=2000-0151 – We miss colorful CVE commentary.

Malware to Vulnerability Mappings.. Anyone?

Unbeknownst to many of us, MITRE’s Common Malware Enumeration (CME) project was declared dead, and apparently has been for a while. What is CME? From their site:

CME was created to provide single, common identifiers to new virus threats and to the most prevalent virus threats in the wild to reduce public confusion during malware incidents. This community effort was not an attempt to replace the vendor names used for viruses and other forms of malware, but instead to facilitate a shared, neutral indexing capability for malware.

With the demise of CME, are there any projects or companies that perform the same role? Specifically, do any maintain mappings between malware and the exploit they use for propagation? Are there any anti-virus vendors that are specifically good about cross-referencing CVE identifiers (or any VDB) to malware?

OSVDB maintains a classification to denote if a vulnerability has been “wormified”, but does not have a mechanism to map more details. When readily available, we will include the malware’s name in keywords, but that is not a flexible solution either. With CME gone, and no obvious vendors or projects that perform this, OSVDB is considering enhancements to fill this void. Before we begin, we’d really like to be sure we aren’t re-inventing a wheel, just replacing a lost wheel (R.I.P. CME). To be clear, we’d only seek to track malware that had a ‘vulnerability’ component to it, not every variation of “CLICKMESTUPID.EXE”. We’ll leave that to the malware detection shops.

What features are sorely lacking from VDBs?

For over ten years, most Vulnerability Databases (VDBs) have done little to evolve. In some cases, they appear to be devolving. OSVDB recognized this many long ago but has struggled for years with a lack of resources, particularly developers. Now that we have saved up enough money, we have hired our only developer part time. Within weeks, Dave has implemented CVSSv2 scoring, enhancements to search, fixes dozens of bugs and already has working mock ups of several additional new features that should fully demonstrate our commitment to evolution. That lead me to think.. while we have dozens of ideas for enhancements and features, what do the users want? Or more to the point, for people who don’t use our database, what features do you find missing from OSVDB or your favorite VDB? What could a VDB do differently, or do better, to make it a (more) valuable resource? No promises on what we can or will implement, but we are all ears. Mail moderators[at]osvdb.org!

OSVDB Content Update

I always mean to post these more often, but I find myself bogged down in adding entries and putting off blog updates. Quite a few little blurbs and thoughts related to OSVDB content.

Changelogs

  • I love vendors who maintain good changelogs. A good changelog has many attributes: version release with date, links to bugs/forums when appropriate, clear but concise language, categorize entries such as ‘security’ or ‘feature’, etc. Further, the changelog should be easy to find and stay updated. Rhinosoft (they maintain many other products as well) is a company that serves as a great example of this.
  • On the flip side, I despise vendors with bad changelogs. One example is IBM who keeps these ridiculously large changelogs, mostly in CAPS with overly vague wording for many issues. As an example, check out this 1.4 meg changelog and try to pick out all the security issues.

Searching OSVDB – Our search engine got an overhaul a while back. While better overall, there are still a few bugs in it. Our dev is going to be available part time come Oct 1, so hopefully they will be knocked out in short order. Until then:

  • If search results seem wrong, try using all lower case or exact case. Known bug that some searches seem to work with one, and not the other.
  • We use keywords when appropriate. This can be useful for example, if you want to see all vulnerabilities in Zoller’s recent multi-browser disclosure. Search All Text for “one bug to rule them all”.
  • Using references as a search field can be valuable. If you want to see all vulnerabilities in PHP (the core language), you can’t title search because of so many PHP applications littering the results. Instead, reference search “php.net” for a concise list.
  • If you search for two terms, it will show results with both words. Searching with three terms will show results with any two words. Known bug! Until fixed, you can work around this by using “+one +two +three” search syntax, with a plus leading each keyword.
  • OSVDB is also tracking vulnerabilities in electronic voting machines. While still in progress, we have scoured the excellent technical reports from the State of California on Premier Election Solutions (formerly Diebold) and have made good progress on Hart InterCivic. To see all of these vulnerabilities, search All Text for “Electronic Voting Machine”.

Historical Content

  • I recently finished combing through the old Zardoz mail list archives. All of the vulnerabilities from that list, operated by Neil Gorsuch between 1989 and 1991, are now in the database. For those interested in historical vulnerabilities, reference search “securitydigest.org/zardoz” to see them. 63 vulnerabilities, only 7 of which have CVE references. Unfortunately, the mail list archive is not complete. If anyone has digests 126, 128, 206, 214, 305, 306, 308, 309, 310 or 314, please send them in!
  • Similar to Zardoz, but already in OSVDB for over a year, you can reference search “securitydigest.org/unix” for the old Unix Security Mailing List disclosed vulnerabilities. There is some overlap with Zardoz here, but it should yield 57 results, 6 of which have a CVE reference.
  • For crypto geeks, you can title search “algorithm” to get a good list of cryptographic algorithms, and when they were demonstrated to be sufficiently weak or completely broken. These go back to 1977 and the New Data Seal (NDS) Algorithm.

Random Notes

  • I recently noticed another case of a vendor threatening mail list archives. Looking at the Neohapsis archive or the lists.grok.org.uk archive of a recent report on Inquira vulnerabilities, you can see each has redacted information. Mail list archives provide a valuable service and typically get little to no benefit for doing so. Despite that, it would be nice if they would post the actual legal threat letter when this occurs.
  • The OSVDB vendor dictionary has been around for a while, but needs additional work. It is the first step in not only providing vendor security contact information, but building a framework for “vendor confidence”. This will eventually allow researchers to determine how cooperative a vendor is and if it is worth their time to responsibly disclose a vulnerability. As it stands, the Vendor Dictionary is primitive and needs to evolve quickly. One example of a problem we ran into, is a researcher submitted a case where they had a ‘bad dealing’ with a given vendor and it is included in the notes. The vendor contacted us, quite surprised to see it, and asked if we agreed with it. I responded that no, that was far from our own dealing with the vendor and that they had been great to work with in disclosing vulnerabilities, providing additional details or answering general questions. Reading our entry on the vendor doesn’t reflect that, and it should. Hopefully in the coming months, with a part time developer, we can begin to address this.
  • When sanitizing takes its toll. BID 28219 has a link to an exploit that appears to have aggressively sanitized characters. Or did the researcher actually send that in? VDBs need to be mindful of this and add a note if they are displaying the submission as is.

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 (http://cve.mitre.org/compatible/compatible.html) 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 (http://cve.mitre.org/compatible/declarations.html). 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:

Status
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.
Phase
Assigned (20090602)
Votes
 
Comments

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:

Status
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.
Phase
Modified (19991210-01)
Votes
ACCEPT(3) Frech, Ozancin, Balinsky
MODIFY(1) Wall
NOOP(1) Baker
REVIEWING(1) Christey
Comments
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:

CVE-ID

CVE-1999-0651

(under review)
• Severity Rating • Fix Information • Vulnerable Software Versions • SCAP Mappings
Description
The rsh/rlogin service is running.
References
Note: References are provided for the convenience of the reader to help distinguish between vulnerabilities. The list is not intended to be complete.
 
Status
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.
Phase
Proposed (19990804)
Votes
ACCEPT(2) Wall, Baker
MODIFY(1) Frech
NOOP(1) Christey
REJECT(1) Northcutt
Comments
Christey> aka "shell" on UNIX systems (at least Solaris) in the
/etc/inetd.conf file.
Frech> associated to:
XF:nt-rlogin(92)
XF:rsh-svc(114)
XF:rshd(2995)

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?

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.

Follow

Get every new post delivered to your Inbox.

Join 6,590 other followers