On September 8, 2016, Jason Levy of WhiteSource Software published a blog titled “Open Source Vulnerability Database”. Almost two years later it came across my radar and I asked via Twitter if WhiteSource was interested in getting feedback on the blog, since it contained errata. They never replied and it fell off my radar. Last week, someone asked me about WhiteSource’s claims about maintaining the largest vulnerability database. While I have not seen it, I expressed doubt and dug into my notes. Until then, I had forgotten that I created notes to write a blog listing the errata. Since their name came up again, I figured it is worth revisiting this, especially since they never replied to me.
First, I was a long-term contributor to OSVDB, an officer in OSF (the 501(c)(3) that managed the project), a founder at Risk Based Security, and one of the maintainers of VulnDB since day one. Don’t worry, all of that is explained in more detail below. Here are quotes from their blog and my thoughts on the errata:
The open source community has been living up to this statement recently, with the accelerated rate of discoveries of open source vulnerabilities reported by such sources as the NVD open source vulnerability database.
CVE/NVD have dismal coverage of open source libraries in the big picture. Their coverage is primarily through a couple dozen projects that seek out CVE IDs, researchers that request CVE IDs, and the OSS-Sec mail list. To date, there are still many developers, projects, and even security researchers that don’t know what CVE is.
The NVD is by far the main source for researching vulnerabilities.
This sentence does not make sense. As you note below, NVD does not research vulnerabilities; they don’t even aggregate vulnerabilities themselves. While many consume NVD’s data over CVE, due to the format they make the data available, more “analysis” is done via CVEDetails.com than NVD in my experience.
Their analysis contains information like how the vulnerability operates, its impact rating, CVSS score, and links to any available patches/fixes.
The main purpose of NVD, aside from a burden on taxpayer’s dollars, is to provide CPE and CVSS scores for vulnerabilities via CVE. They rarely, if ever, do additional analysis of the vulnerability unless required to determine a CVSS score. If they do, they do not “show their work” so to speak, instead using the same CVE description. As best I am aware, they don’t dig up additional references either, so the only solution links provided are via CVE. That said, I haven’t audited NVD in several years to see if that still holds true, but I would be surprised if anything has changed.
The OSVDB (open source vulnerability database) was launched in 2004 by Jake Kouhns, the founder and current CISO of Risk Based Security – the company which now operates OSVDB’s commercial version, the VulnDB.
Jake Kouns, one of the founders of Risk Based Security (RBS) did not launch OSVDB. And that is the Open Sourced Vulnerability Database. OSVDB was created and launched by H.D. Moore. More history is available via Wikipedia. While OSVDB was a basis for the historical data in VulnDB, Risk Based Security funded OSVDB entirely for over two years and it was their data that was shared publicly via OSVDB before the project shut down. When OSVDB shut down, RBS continued to maintain VulnDB which contains over eight years of vulnerability information not found in OSVDB. With considerable resources and a team maintaining VulnDB, it has become something OSVDB wished it could, but never came close.
This commercial version continues to be maintained by Risk Based Security, but without the strong community that maintained the OSVDB.
There was no “strong community” that maintained OSVDB. For years, it limped along on the backs of a handful of volunteers, with very little support from the community; financial or labor. At times, there were only two of us maintaining the project while most volunteers signed up, worked on the database for 20 minutes, and never returned to help again.
The OSVDB/VulnDB is perceived by many in the community as redundant, for the majority of vulnerabilities are also reported in the NVD.
This is WhiteSource’s ignorance or bias at play. OSVDB was known for having tens of thousands of vulnerabilities not found in CVE/NVD. One of VulnDBs strong points is that it contains almost 69,000 vulnerabilities not found in CVE/NVD. Since WhiteSource claims to have a comprehensive database, you should have disclaimed this while spreading false information about VulnDB. Since VulnDB is not public, the notion that is perceived by “many” in such a light is just your marketing. Anyone reading VulnDBs quarterly or year-end reports can see the incredible gap between them and CVE/NVD. Also curious is that the link off “monitoring of multiple vulnerability databases including the CVE/NVD” just links to your blog on the topic. Other than CVE/NVD, which vulnerability databases do you monitor exactly?
I’d also happily sign a non-disclosure agreement to do a quick audit of your database, to verify or refute your claim that you have the “the largest coverage of vulnerability listings“. I’d only ask that in return, I can publish a simple ‘yes’ or ‘no’ answer to that claim.
Security advisories are usually the first place that security professionals and developers look when they have security issues within a specific scope.
If this is WhiteSource’s methodology for maintaining a vulnerability database, it does not bode well for your customers. Formal security advisories are quickly becoming, or have already become, a minority in the disclosure game. OSVDB and VulnDB didn’t stay far ahead of the curve using this antiquated mindset. We knew to look elsewhere all along.
WhiteSource tracks almost a dozen security advisories (like RubyOnRails, RubySec and Node Security), to ensure our customers are alerted on new vulnerabilities the minute they’re reported.
A whole dozen? The VulnDB team currently monitors 3,100 sources every week. Some are monitored ~ hourly, some a few times a day, some once a week depending on various criteria such as publication frequency. If WhiteSource is only looking at those sources, and that type of source, it really doesn’t bode well for your claims of the largest vulnerability listing.
The majority of vulnerabilities are published with a remediation suggestion, like a new patch, new version, system configuration suggestion etc.
While technically true, per VulnDB data, it is better to qualify that. For example, in Q1 2019, 60.8% of disclosed vulnerabilities they aggregated had a documented solution. But, a couple caveats. First, that was down 13.5% over Q1 2018! Second, not all solutions are created equal. Just because there is a patch committed against the ‘master’ branch doesn’t mean an organization can actually use it. Their policy or available resources may not allow for one-off code patching like that.
And here at WhiteSource, this is exactly what we do.
Unfortunately, based on the way you describe what you do, you are not much better than CVE/NVD I’m afraid.
This has been a long-recognized and proven thing, but every year we run into more glaring examples. SecurityFocus, who runs the BID database, which is part of Symantec’s DeepSight offering, routinely uses submissions to the Bugtraq mail list to seed their commercial database, sometimes days before approving the post. This means subscribers who use Bugtraq as one of many sources of ‘real-time’ vulnerability intelligence routinely get the short end of the stick. Full-Disclosure, managed by Fyodor and team, do not have that commercial interest in the content of the posts to the FD. Their average turnaround time seems to be considerably better in approving posts. So please, for the industry’s sake, post to Full-Disclosure and stop supporting Bugtraq.
Today’s example: A new CVE popped up in various places. Google showed the first hit to be the BID Database:
EMC only posts their advisories to the Bugtraq list, so we checked there first, since that would be the provenance:
There are EMC advisories visible, but not the one with CVE-2017-4985. Checking again today:
SecurityFocus delayed the post by three days while it was in their database.
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).
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., email@example.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 firstname.lastname@example.org 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.
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.
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.
#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 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.
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.
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.
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.
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!
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 “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”.
- 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.
- 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.