Posted by jkouns
Sat, 06 Feb 2010 06:27:00 GMT
The Open Security Foundation (OSF) has grown from a humble beginning in 2004 to an internationally recognized 501(c)(3) non-profit public organization. Through the work of a small team of dedicated information security enthusiasts, the Open Source Vulnerability Database (OSVDB) and DataLossDB projects have provided organizations of all sizes with the knowledge and resources to accurately detect, protect and mitigate information security risks. OSF research is often cited throughout the security industry and the organization was honored by being named winner of the SC Magazine's Editors Choice award for 2009.
To ensure the highest quality information that has become the trademark of OSF, a tremendous amount of effort is expended on a daily basis by OSF volunteers to process an ever increasing amount of data loss and vulnerability reports. Over the years, many volunteers have been involved in the projects, but for the most part the the heavy lifting has been the work of only a few very dedicated volunteers. The "open source" approach to resourcing the projects has been successful to date but is now proving to be an unsustainable model. With long-term sustainability and increased services as our goal, we have initiated a comprehensive review of our current operations, our existing approach to project funding and the creation of potential new services for the security community.
As a start, we plan to do a better job of sharing our view on the state of the information security industry and creating a mechanism to gain community feedback to better establish our vision for the OSVDB and DataLossDB projects.
To that end I want to take a moment to share our initial plans for 2010.
The OSF officers and project leads have been dedicated to the daily operations required to make OSVDB and DataLossDB the recognized leader in vulnerability and data loss tracking. This focused dedication has left little time to take the pulse of the industry as it relates to our projects or to establish a clear long-term vision for the projects. To address this need, OSF will be creating an Advisory Board. The board will consist of three to five senior leaders capable of providing broad based perspective on information security, business management and fundraising. It is our hope that this will provide a sounding board when developing future plans, an open forum when reviewing community feedback and a broader view when prioritizing potential new services. Additional information along with an official call for Advisory Board nominations is planned for 2/12/2010.
Direct unfiltered feedback from both the security community as well as the organizations that benefit from our projects is critical. Over the next few weeks, we plan to post a public survey asking for feedback that will help shape our long-term vision and establish our near-term plans for OSVDB and DataLossDB. Those of you who value the work that the OSF provides and/or consider yourselves friends and supporters of OSF are asked to help spread the word to maximize the feedback provided.
Feedback from the survey will be the foundation for the OSF vision and 2010 plan. Our goal is to present a draft of both the vision and the 2010 plan to the newly formed Advisory Board by mid-April 2010. Once finalized, both documents will be shared with the information security community.
OSF has been recognized for providing a critical service to the information security community but our potential is much greater. We look forward to hearing your ideas on how OSF can further improve the state of security while building a stronger organization to deliver even higher quality research and additional services.
Chairman, Open Security Foundation
Posted in OSVDB News | no comments
Posted by lyger
Mon, 01 Feb 2010 05:19:00 GMT
Well, it's been almost a month since we issued our original challenge for the "OSVDB Winter 2010 Fundraising Goal". As mentioned in our initial post, we're pretty transparent about how much work we do on a daily/weekly/monthly basis. Thanks to Twitter, pico, and my /home/lyger/wtf-ever folder, we present January's results:
2010-01-01: 23 vulns pushed, 56 vulns updated
2010-01-02: 21 vulns pushed, 194 vulns updated
2010-01-03: 11 vulns pushed, 143 vulns updated
2010-01-04: 25 vulns pushed, 104 vulns updated
2010-01-05: 50 vulns pushed, 184 vulns updated
2010-01-06: 13 vulns pushed, 94 vulns updated
2010-01-07: 15 vulns pushed, 78 vulns updated
2010-01-08: 33 vulns pushed, 162 vulns updated
2010-01-09: 1 vulns pushed, 127 vulns updated
2010-01-10: 17 vulns pushed, 208 vulns updated
2010-01-11: 30 vulns pushed, 325 vulns updated
2010-01-12: 32 vulns pushed, 385 vulns updated
2010-01-13: 21 vulns pushed, 119 vulns updated
2010-01-14: 18 vulns pushed, 79 vulns updated
2010-01-15: 26 vulns pushed, 199 vulns updated
2010-01-16: 65 vulns pushed, 102 vulns updated
2010-01-17: 15 vulns pushed, 75 vulns updated
2010-01-18: 21 vulns pushed, 130 vulns updated
2010-01-19: 20 vulns pushed, 48 vulns updated
2010-01-20: 22 vulns pushed, 142 vulns updated
2010-01-21: 18 vulns pushed, 83 vulns updated
2010-01-22: 16 vulns pushed, 86 vulns updated
2010-01-23: 16 vulns pushed, 27 vulns updated
2010-01-24: 6 vulns pushed, 30 vulns updated
2010-01-25: 25 vulns pushed, 114 vulns updated
2010-01-26: 8 vulns pushed, 70 vulns updated
2010-01-27: 16 vulns pushed, 90 vulns updated
2010-01-28: 26 vulns pushed, 87 vulns updated
2010-01-29: 20 vulns pushed, 28 vulns updated
2010-01-30: 14 vulns pushed, 52 vulns updated
2010-01-31: 11 vulns pushed, 40 vulns updated
As of early morning February 1, we have pushed 655 new vulnerabilities into the database since the beginning of 2010. Please take a moment to look at the dates listed above; if you find a day missing from January, please let us know. Yes, we laid off on the 9th (Jericho made the save with OSVDB 61571 : EcShop /admin/integrate.php Multiple Parameter Arbitrary Command Execution), but the honest fact is that we generally work on OSVDB *every day* in some form. Some days are slower than others, sure... we still have families, friends, and other hobbies (believe it or not). Actually, the number of OSVDB moderators who own a Wii with the Fit Plus package is scary, but I digress.
So, about the challenge we presented... I'm still willing to put up $0.50 HARD U.S. DOLLARS for every new vulnerability we push from January 1, 2010 through April 1, 2010. I pushed it through April 1 and not just March 31 because a) April 1 is a much cooler day to end a contest, 2) February 29 is a special day and should never be left out of any year, so an extra day was warranted, and d) that's the period that Dave set up the end of the fundraising goal for, and we try to keep him happy so things don't randomly 500 when we do something like enter weird support tickets..
Any company or person who still wants to match my offer, please feel free to do so. Even though we're only at about 2/3 of our usual push rate, we're not intentionally laying back to keep the new vulnerability count lower. Coming off a holiday season takes time to get back in the groove, not only for us but our reference providers as well. Please mail us at our moderators@ address if you want to contribute.
Posted in OSVDB News, Vulnerability Databases | no comments
Posted by jericho
Sun, 24 Jan 2010 11:35:00 GMT
Perhaps it is the fine tequila this evening, but I really don't get how our industry can latch on to the recent 'Aurora' incident and try to take Microsoft to task about it. The amount of news on this has been overwhelming, and I will try to very roughly summarize:
News surfaces Google, Adobe and 30+ companies hit by "0-day" attack
Google uses this for political overtones
Originally thought to be Adobe 0-day, revealed it was MSIE 0-day
Jan 14, confirmed it is MSIE vuln, shortly after dubbed "aurora"
Jan 21, uproar over MS knowing about the vuln since Sept
Now, here is where we get to the whole forest, trees and some analogy about eyesight. Oh, I'll warn (and surprise) you in advance, I am giving Microsoft the benefit of the doubt here (well, for half the blog post) and throwing this back at journalists and the security community instead. Let's look at this from a different angle.
The big issue that is newsworthy is that Microsoft knew of this vulnerability in September, and didn't issue a patch until late January. What is not clear, is if Microsoft knew it was being exploited. The wording of the Wired article doesn't make it clear: "aware months ago of a critical security vulnerability well before hackers exploited it to breach Google, Adobe and other large U.S. companies" and "Microsoft confirmed it learned of the so-called 'zero-day' flaw months ago". Errr, nice wording. Microsoft was aware of the vulnerability (technically), before hackers exploited it, but doesn't specifically say if they KNEW hackers were exploiting it. Microsoft learned of the "0-day" months ago? No, bad bad bad. This is taking an over-abused term and making it even worse. If a vulnerability is found and reported to the vendor before it is exploited, is it still 0-day (tree, forest, no one there to hear it falling)?
Short of Microsoft admitting they knew it was being exploited, we can only speculate. So, for fun, let's give them a pass on that one and assume it was like any other privately disclosed bug. They were working it like any other issue, fixing, patching, regression testing, etc. Good Microsoft!
Bad Microsoft! But, before you jump on the bandwagon, bad journalists! Bad security community!
Why do you care they sat on this one vulnerability for six months? Why is that such a big deal? Am I the only one who missed the articles pointing out that they actually sat on five code execution bugs for longer? Where was the outpour of blogs or news articles mentioning that "aurora" was one of six vulnerabilities reported to them during or before September, all in MSIE, all that allowed remote code execution (tree, forest, not seeing one for the other)?
| CVE |
Reported to MS |
Disclosed |
Time to Patch |
| CVE-2010-0244 |
2009-07-14 |
2010-01-21 |
6 Months, 7 Days (191 days) |
| CVE-2010-0245 |
2009-07-14 |
2010-01-21 |
6 Months, 7 Days (191 days) |
| CVE-2010-0246 |
2009-07-16 |
2010-01-21 |
6 Months, 5 Days (189 days) |
| CVE-2010-0248 |
2009-08-14 |
2010-01-21 |
5 Months, 7 days (160 days) |
| CVE-2010-0247 |
2009-09-03 |
2010-01-21 |
4 Months, 18 days (140 days) |
| CVE-2010-0249 |
2009-09-?? |
2010-01-14 |
4 Months, 11 days (133 days) - approx |
| CVE-2010-0027 |
2009-11-15 |
2010-01-21 |
2 Months, 6 days (67 days) |
| CVE-2009-4074 |
2009-11-20 |
2009-11-21 |
2 Months, 1 day (62 days) |
Remind me again, why the "Aurora" conspiracy is noteworthy? If Microsoft knew of six remote code execution bugs, all from the September time-frame, why is one any more severe than the other? Is it because one was used to compromise hosts, detected and published in an extremely abnormal fashion? Are we actually trying to hold Microsoft accountable on that single vulnerability when the five others just happened not to be used to compromise Google, Adobe and others?
Going back to the Wired article, they say on the second to last paragraph: "On Thursday, meanwhile, Microsoft released a cumulative security update for Internet Explorer that fixes the flaw, as well as seven other security vulnerabilities that would allow an attacker to remotely execute code on a victim’s computer." Really, Wired? That late in the article, you gloss over "seven other vulnerabilities" that would allow remote code execution? And worse, you don't point out that Microsoft was informed of five of them BEFORE AURORA?
Seriously, I am the first one to hold Microsoft over the flames for bad practices, but that goes beyond my boundaries. If you are going to take them to task over all this, at least do it right. SIX CODE EXECUTION VULNERABILITIES that they KNEW ABOUT FOR SIX MONTHS. Beating them up over just one is amateur hour in this curmudgeonly world.
Posted in Vulnerability Disclosure | no comments
Posted by lyger
Tue, 05 Jan 2010 03:16:00 GMT
OSVDB has just announced its Winter 2010 Fundraising Goal , which currently hopes to raise $9,000 before April 1, 2010. Looking back over the last couple of years of advances in the project, it's easy to see not only how the project has evolved, but also how operational costs have increased to cover software development, content development, server hosting costs, and other assorted expenses to help keep OSVDB interesting, timely, and functional.
On an average, OSVDB has promoted 10,000 to 12,000 vulnerabilites per year for the last the last few years. Breaking that down to about 1,000 per month, the vulnerabilities in the database are gathered from a variety of sources, such as CVE, Secunia and various vendor changelogs and advisories. Keeping up a pace of about 1,000 newly listed vulerabilities per month hasn't always been easy... but it's about to get interesting.
I recently resigned my position as Chief Communications Officer with Open Security Foundation to focus more on the "content" aspect of OSVDB and DataLossDB. The extra time gained from giving up administrative duties will hopefully help the sites keep content fresh and accurate. Jericho, CJI, and I are going to keep working on new vulnerabilities as we can and keep the ball rolling.
With that said, I'm issuing a challenge: For every new vulnerability issued an OSVDB ID from January 1, 2010 through April 1, 2010, I will donate $0.50 (fiddy cents) of my own money to the OSVDB fundraiser. I challenge anyone who feels that OSVDB is a valuable resource to the security community to match my donation.
To make a few points clear:
1. I am no longer an OSF officer. My donation comes out of my own pocket, not the OSF coffers, and I will accept no compensation from OSF for this offer. If I have to sell a kidney, I hear you only need one anyway.
2. Since Jericho, CJI, and I are the ones who generally push new vulnerabilities to "live" status, there will be no slacking to save my bank account. If anything, I'll be more motivated to push the potential donations higher and they'll be motivated to watch me suffer on April 2. That's how we roll.
3. At an average of 1,000 vulnerabilities a month, over three months I expect to donate $1,500. It may be less, it may be more. There will be a maximum cap of $2,500 donated by myself and anyone who matches it. If we can push 5,000 vulns in three months, something is either very wrong or very great. YMMV.
4. If five other people and/or groups take me up on the challenge and we meet our average, OSF will meet its goal. We still hope everyone else will contribute not only time but *effort* to help the project.
5. This is not a gimmick. It's not smoke and mirrors. You can see what OSVDB pushes on a daily basis on our Twitter page and on our contributors page. We will push all legitimate vulnerabilities just as we have been doing for years. If we're slow for a few days, don't worry. We'll catch up.
So, that's the challenge. If anyone wants to play and match my offer, please contact us at moderators[at]osvdb.org. I'm going back to work now.
Posted in OSVDB News | no comments
Posted by jericho
Sat, 19 Dec 2009 21:07:00 GMT
Elinor Mills wrote an article titled Firefox, Adobe top buggiest-software list. In it, she quotes Qualys as providing vulnerability statistics for Mozilla, Adobe and others. Qualys states:
The number of vulnerabilities in Adobe programs rose from 14 last year to 45 this year, while those in Microsoft software dropped from 44 to 41, according to Qualys. Internet Explorer, Windows Media Player and Microsoft Office together had 30 vulnerabilities.
This caught my attention immediately, as I know I have mangled more than 45 Adobe entries this year.
First, the "number of vulnerabilities" game will always have wiggle room, which has been discussed before. A big factor for statistic discrepancy when using public databases is the level of abstraction. CVE tends to bunch up vulnerabilities in a single CVE, where OSVDB tends to break them out. Over the past year, X-Force and BID have started abstracting more and more as well.
Either way, Qualys cited their source, NVD, which is entirely based on CVE. How they got 45 vulns in "Adobe programs" baffles me. My count says 97 Adobe vulns, 95 of them have CVEs assigned to them (covered by a total of 93 CVEs). OSVDB abstracted the entries like CVE did for the most part, but split out CVE-2009-1872 as distinct XSS vulnerabilities. OSVDB also has two entries that do not have CVE, 55820 and 56281.
Where did Qualys get 45 if they are using the same CVE data set OSVDB does? This discrepancy has nothing to do with abstraction, so something else appears to be going on. Doing a few more searches, I believe I figured it out. Searching OSVDB for "Adobe Reader" in 2009 yields 44 entries, one off from their cited 45. That could be easily explained as OSVDB also has 9 "Adobe Multiple Products" entries that could cover Reader as well. This may in turn be a breakdown where Qualys or Mills did not specify "Adobe Software" (cumulative, all software they release) versus "Adobe Reader" or some other specific software they release.
Qualys tallied 102 vulnerabilities that were found in Firefox this year, up from 90 last year.
What is certainly a discrepancy due to abstraction, OSVDB has 74 vulnerabilities specific to Mozilla Firefox (two without CVE), 11 for "Mozilla Multiple Browsers" (Firefox, Seamonkey, etc) and 81 for "Mozilla Multiple Products" (Firefox, Thunderbird, etc). While my numbers are somewhat anecdotal, because I cannot remember every single entry, I can say that most of the 'multiple' vulnerabilities include Firefox. That means OSVDB tracked as many as, but possibly less than, 166 vulnerabilities in Firefox.
Microsoft software dropped from 44 to 41, according to Qualys. Internet Explorer, Windows Media Player and Microsoft Office together had 30 vulnerabilities.
According to my searches on OSVDB, we get the following numbers:
- 234 vulnerabilities in Microsoft, only 4 without CVE
- 50 vulnerabilities in MSIE, all with CVE
- 4 vulnerabilities in Windows Media Player, 1 without CVE
- 52 vulnerabilities in Office, all with CVE. (based on "Office" being Excel, Powerpoint, Word and Outlook.
- 92 vulnerabilities in Windows, only 2 without CVE
When dealing with vulnerability numbers and statistics, like anything else, it's all about qualifying your numbers. Saying "Adobe Software" is different than "Adobe Acrobat" or "Adobe Reader" as the software installation base is drastically different. Given the different levels of abstraction in VDBs, it is also equally important to qualify what "a vulnerability" (singular) is. Where CVE/NVD will group several vulnerabilities in one identifier, other databases may abstract and assign unique identifiers to each distinct vulnerability.
Qualys, since you provided the stats to CNet, could you clarify?
Posted in Vulnerability Statistics | Tags cnet, qualys | 4 comments
Posted by jericho
Tue, 08 Dec 2009 22:50:00 GMT
I always mean to post changes more frequently, but apathy and other tasks seem to win the day. Here is a brief list of OSVDB change highlights over the past few months.
Content:
Search:
Other:
Posted by jericho
Sat, 21 Nov 2009 23:00:00 GMT
Thanks to Dave, we now have a completely re-written creditee system. For years, we operated off a four field system (name, email, company, url) for tracking vulnerability researchers. While we tracked that information, it was not flexible and led to serious problems with data integrity. Even worse, it didn't allow for long term tracking of a researcher's disclosure history. There were several cases where the system couldn't handle proper data tracking, for example:
- If John Doe works for CompX and discloses a vulnerability, that becomes set in stone as associated with his name. This is problematic if John Doe goes to CompZ and discloses additional vulnerabilities.
- The above scenario is even more problematic if John Doe then releases a vulnerability through a program such as iDefense or ZDI.
- If two researchers shared the same name, there was no way to differentiate them.
While creating a creditee system to track this may seem straightforward, it is surprisingly difficult. After a lot of brainstorming and trying to determine where the system may fall short, we came up with something. What we are now referring to as "creditee v2" will be used with a clean set of data. All previous creditee data entered is labeled (internally) as "v1" and will only display if there is no v2 data.
The new creditee system is a bit more complex, but allows for one individual to be associated with multiple e-mail addresses, companies or organizations. We can also now track the country of the researcher and company separately
to account for multi-national companies. With a better data set, we can now do a lot more analysis and generate interesting statistics for vulnerability researchers. As an example of the new system, you can now easily see all vulnerabilities associated with your name, e-mail addresses and affiliations. Clicking on the affiliation will show all researchers and the vulnerabilities disclosed by a given organization.
Even better, this system allows for one click access to your prior vulnerability disclosures. This could be useful for resumes, web page bios and more. We fully encourage you to "ego mangle" to help us fill in the data. Create an account, find your vulnerabilities in the database and fill in the details associated with that disclosure. Note: we are tracking the information associated with the disclosure, not necessarily your current e-mail or affiliation. If you can't find your vulnerability in the database, mail moderators[at]osvdb.org with details. We'll help you find it or add it in case it is missing. We're still working out several bugs in the system, but this is a great overhaul and a foundation of another long term feature enhancement: "researcher confidence".
Posted in OSVDB News | Tags confidence, creditee, researcher | no comments
Posted by jericho
Sun, 15 Nov 2009 11:27:00 GMT
Earlier this evening, there was a Twitter debate regarding a proposed standard for responsible vulnerability disclosure. It referred to ISO/IEC 29147, a proposed standard for responsibly disclosing a vulnerability. @dinodaizovi brought up a fresh angle, that the "responsible disclosure" name itself completely ignored the aspect of the vendor practicing "responsible remediation". That term should really be more in the center of our minds and discussion. The lack of "responsible remediation" is why so many researchers are fed up with dealing with vendors. That is one reason some use services like ZDI or iDefense, not just the cash.
The "responsible disclosure" debate is stale for the most part. We'll never agree on how much time is 'right' for a vendor to fix a vulnerability. Some researchers think it's days, other think weeks or months. In the paraphrased words of some female vendor on some boring responsible disclosure panel a few years back, "if i can have a kid in 9 months, i should be able to fix a vulnerability too". Yet 9 months isn't reasonable to some vendors like HP, who routinely break the 1,000 day mark, even for simple XSS.
@mckeay brought up another aspect to the responsible disclosure debate that was actually fresh, asking what part consumers played in the disclosure process. While I believe it is a neat aspect and something most haven't considered, I personally believe it is quickly answered by "consumers can put financial pressure on vendors that don't play well with others". In reality, consumers are lazy. It takes more than a few bad acts to get us to spend time an energy finding a new vendor. Short of anally raping us with a router and pouring lemon juice in our festering wound,
nine times out of ten, we will not find a new vendor.
Back to @dinodaizovi. He is right, any standard for disclosure should be equally centered on the vendor as it is for the researcher. Researchers can easily fall back on RFP's "rfpolicy" disclosure policy and change X days to something they believe in. The framework is still perfectly valid and outlines the process, the time frames are always up for debate.
What if we carried this one step beyond? How about making the ISO standards apply to any and every vulnerability, regardless of who found it? If BigVendor finds a vulnerability during internal testing and fixes it, don't consumers have a right to know? When BigVendor says "upgrade to Service Pack 18" and only gives us a reason of "big stability enhancements!!", shouldn't we have a right to know those enhancements translate into 17 remotely exploitable vulnerabilities discovered during internal testing and QA? Wouldn't *that* knowledge be a more significant
reason to upgrade and apply the service pack?
I realize it is a pipe dream to think that most vendors would ever offer that level of transparency, even months (years?) after a given issue is fixed. In reality though, they are the proverbial large mythical flightless birds who stick their heads in the sand rather than face a difficult situation (ostriches are real and don't bury their heads). It has been proven countless times that serious vulnerabilities in big vendors (e.g., Microsoft, Apple, Adobe) are being discovered by multiple parties. No one with an inkling of common sense and rational thinking can believe that the 'bad guys' aren't also discovering some of these bugs. We're long past the point of vendors honestly thinking that they can get away with some notion that they have a reputation for 'security'. Add it up, and we're to that time where the big vendors should be disclosing vulnerabilities discovered during their internal QA / SLDC process. The reputation of insecure software really can't hurt them any more, and transparency is finally the one thing that could buy back some degree of consumer confidence.
Perhaps now is the time where 'responsible disclosure' should apply equally to hackers, security researchers and vendors, as well as apply to 'responsible remediation'. Because really, some 20 years after the disclosure debate got going, do we really think we need to try to apply more guidelines to researchers giving away $250/hr consulting work or "hackers" posting vulnerabilities as a hobby? Vendors that have tried to label or apply policy to these people were simply blame-shifting from day one, while not applying that desired policy to themselves.
Posted in Vulnerability Disclosure | Tags alexsotirov, attritionorg, daveaitel, dinodaizovi, dragosr, k8emo, mckeay, mdowd, simplenomad | 2 comments
Posted by jericho
Mon, 09 Nov 2009 19:59:00 GMT
Last week, OSVDB enhanced the search results capability by adding a considerable amount of filter capability, a simple "results by year" graph and export capability. Rather than draft a huge walkthrough, open a search in a new tab and title search for "microsoft windows".
As always, the results will display showing the OSVDB ID, disclosure date and OSVDB title. On the left however, are several new options. First, a summary graph will be displayed showing the number of vulnerabilities by year, based on your search results. Next, you can toggle the displayed fields to add CVE, CVSSv2 score and/or the percent complete. The percent complete refers to the status of the OSVDB entry, and how many fields have been completed. Below that are one click filters that let you further refine your search results by the following criteria:
- Reference Type - only show results that contain a given type of reference
- Category - show results based on the vulnerability category
- Disclosure Year - refine results by limiting to a specific year
- CVSS Score - only show entries that are scored in a given range
- Percent Complete - filter results based on how complete the OSVDB entry is
Once you have your ideal search results, you can then export them to XML, custom RSS feed or CSV. The export will only work for the first 100 results. If you need a bigger data set to work with, we encourage you to download the database instead.
With the new search capability, you should be able to perform very detailed searches, easily manipulate the results and even import them into another application or presentation. If you have other ideas of how a VDB search can be refined to provide more flexibility and power, contact us!
Posted in Vulnerability Statistics, OSVDB News | Tags export, search | no comments
Posted by jericho
Mon, 09 Nov 2009 10:16:00 GMT
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.
Posted in Vulnerability Databases | Tags CVE, history, humor | 1 comment
