Category Archives: Vulnerability Databases

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.,

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 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.


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. – CVE contributors can be stumped – Client side vulnerabilities aren’t an issue. – No reference, no problem! – ISS tried desperately to help. – A CVE entry can be a duplicate of itself. – 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 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.


  • 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 “” 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 “” 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 “” 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 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 ( 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.

If You Can’t, How Can We?

Steve Christey w/ CVE recently posted that trying to keep up with Linux Kernel issues was getting to be a burden. Issues that may or may not be security related, even Kernel devs don’t fully know. While this is a good example of the issues VDBs face, it’s really the tip of the iceberg. Until their recent adoption of CVE identifiers, trying to distinguish Oracle vulnerabilities from each other was what you did as a gentle relief from a few hours of being water-boarded. Lately, Mozilla advisories are getting worse as they clump a dozen issues with “evidence of memory corruption” into a single advisory, that gets lumped into a single CVE. Doesn’t matter that they can be exploited separately or that some may not be exploitable at all. Reading the bugzilla entries that cover the issues is headache-inducing as their own devs frequently don’t understand the extent of the issues. Oh, if they make the bugzilla entry public. If the Linux Kernel devs and Mozilla browser wonks cannot figure out the extent of the issue, how are VDBs supposed to?

Being “open source” isn’t some get-out-of-VDB free card. You’re supposed to be better than your closed-source rivals. You’re supposed to care about your customers and be open about security issues. An advisory full of “may” and “evidence of” is nothing more than a FUD-filled excuse to blindly upgrade without understanding the real threat or exposure to the end-user.

Steve’s post is a good view of how some VDBs feel about the issue:

Tonight, I followed-up on his thoughts and gave more of my own (original:

A question, really?

I’d like to reiterate what Steve Christey said in the last 24 hours, about the Linux Kernel vulnerabilities becoming a serious drain on CVE. Historically, OSVDB has relied on Secunia and CVE to sort out the Linux Kernel vulnerability messes. Both VDBs have full time staff that can dedicate time to figuring out such nuances as those above.

Not to pick on Eugene specifically, but I feel he makes a great example of my point. Nuances that a “Senior Security Engineer at Red Hat” who specialies in “OS and Application Security, Project Management, Vulnerability Analysis, Code-level Auditing, Penetration Testing, Red Hat Products and Services, Financial Services Technical Account Management” cannot definitely distinguish between difference in Kernel vulnerabilities. If Eugene cannot say with certainty these deserve two CVE numbers, how can Steve or his staff?

VDBs deal with thousands of vulnerabilities a year, ranging from PHP applications to Oracle to Windows services to SCADA software to cellular telephones. We’re expected to have a basic understanding of ‘vulnerabilities’, but this isn’t 1995. Software and vulnerabilities have evolved over the years. They have moved from straight-forward overflows (before buffer vs stack vs heap vs underflow) and one type of XSS to a wide variety of issues that are far from trivial to exploit. For fifteen years, it has been a balancing act for VDBs when including Denial of Service (DOS) vulnerabilities because the details are often sparse and it is not clear if an unprivileged user can reasonably affect availability. Jump to today where the software developers cannot, or will not tell the masses what the real issue is.

This isn’t just a Linux Kernel issue at all. The recent round of advisories from Mozilla contain obscure wording that allude to “memory corruption” implying arbitrary code execution. If you follow the links to the bugzilla reports, the wording becomes a quagmire of terms that not even the developers can keep up on [1] [2]. That’s if they even open the bugzilla entry reference in the advisory [3]. Again, how are people not intimately familiar with the code base supposed to understand these reports and give a reasonable definition of the vulnerability? How do we translate that mess of coder jargon into a 1 – 10 score for severity?

It is important that VDBs continue to track these issues, and it is great that we have more insight and contact with the development teams of various projects. However, this insight and contact has paved the way for a new set of problems that over-tax an already burdened effort. MITRE receives almost 5 million dollars a year from the U.S. government to fund the C*E effort, including CVE [Based on FOIA information]. If they cannot keep up with these vulnerabilities, how do their “competitors”, especially free / open source ones [5], have a chance?

Projects like the Linux Kernel are familiar with CVE entries. Many Linux distributions are CVE Numbering Authorities, and can assign a CVE entry to a particular vulnerability. It’s time that you (collectively) properly document and explain vulnerabilities so that VDBs don’t have to do the source code analysis, patch reversals or play 20 questions with the development team. Provide a clear understanding of what the vulnerability is so that we may properly document it, and customers can then judge the severity of issue and act on it accordingly.

I believe this is a case where over-exposure to near-proprietary technical details of a product have become the antithesis of closed-source vague disclosures like those from Microsoft or Oracle [Which are just as difficult to deal with in a totally different way.].


Get every new post delivered to your Inbox.

Join 6,043 other followers