Yesterday, we experienced a catastrophic failure on the primary system hosting OSVDB that initially appears to be related to a drive failure. We are working with our hosting provider but have yet to determine root cause and we currently do not have an ETA as to when the site will be restored.
6/12/2015 Update: After fighting with the disks, the site has been restored and functioning. Apologies for the downtime!
6/14/2015 Update: Days after getting it fixed, the box tanked again. We’re working on it, while cursing technology.
8/3/2015 Update: The system has been back up since ~ 6/16. We just spaced it and forgot to update the blog. Apologies!
UPDATE: Shortly after the initial draft of this blog was written (but days before it was published), David mailed again shortly after my reply to apologize and clear up that any notion of a legal threat was not intended. Note that his reply was not sent to the same addresses he originally mailed, or the ones that were added in our reply, so it was not immediately seen. He went on to say that he “fired off an email quickly on my own in frustration without talking to anyone before hand or letting anyone else preview it“. As such, we have edited this post to mostly redact the company name as well as fully redact David’s last name. It is not our intent to punish anyone and we understand and appreciate that such actions are often misunderstood and not intended. We now hope that this blog post can serve as a lesson to everyone, ourselves included, about how emails can be perceived from both vendors, and vulnerability databases.
As most people who follow the OSVDB project know, we strive for the most complete and accurate information about vulnerabilities. We take it very seriously, almost to a fault. We actively seek out information from the community and routinely contact vendors and researchers directly to confirm we have a clear understanding of the information published. When we are provided more clarity we update our entries without hesitation. However, when we receive an email from a vendor with a “legal issue” in the subject and it tells us to change an entry without new evidence, this concerns us as it goes against the core of the project to provide accurate, detailed, current, and unbiased technical security information.
In keeping with our mission to help educate both vendors and researchers on how best to handle the vulnerability disclosure process, we believe it is in the interest of the community to publish details if a software vendor uses legal action, or the implied threat of legal action, to silence vulnerability information. Typically when we have vendors contact us they want to have an entry removed completely, but that was not the case in this situation. In this case, rather than try to work with us to ensure the entry is accurate we received an email from a large medical vendor that “suggested” we change published information so that it would no longer be factual.
David, who sent the mail, said he would follow up the next day with us but did not. As we shared with him on Friday in our reply, we would write a blog about the incident on Monday to ensure that everyone was made aware of the situation. Below are the two emails exchanged, only edited for formatting. No content has been removed or altered.
We respect vendor concerns about entries, and will flag “Vendor Disputed” immediately when we are contacted. We will then examine their concerns and make changes appropriately. In this case, the vendor has verified the vulnerability itself, but they are disputing the access vector. This may not seem like a big deal, but we take the “accurate information” guiding principle very seriously. Our vulnerability entry is currently using the CVSSv2 scoring from NVD at 4.3 publicly. The associated CERT/VU scoring has it at 7.4. We believe the score should really be 10.0 due to the vulnerability being remote default hardcoded credentials that allow full access to the database. Changing the access vector from remote to local, as the vendor requested, could result in a score as low as 1.9. Remember, while CVSSv2 has some faults, the base scoring system is still done according to the “constant with time and across user environments”. That means that third-party protection mechanisms like firewalls, routers, or other screening devices are not factored into scoring.
If any entry containing technically inaccurate information needs to be updated, we are happy to do so immediately provided there is sufficient evidence available. This has been our policy for almost 10 years now, and it will not change. Threatening legal action over something so trivial, without trying to resolve it amicably, seems counterproductive.
To: OSVDB moderators
Date: Fri, 17 May 2013 12:31:51 -0400
Subject: [OSVDB Mods] Legal issue and web site problem
1) When clicking on comment the web site returns a 500 error. As a result comments are not allowed on VBD items and owners of the software are not able to dispute misrepresentations in the posts.
2) Contains a fundamental misrepresentation of the original CERT posting which we will dispute with any and all means necessary. Please correct the post to indicate that the issue is not remotely exploitable which is clearly evident in the CERT post description, the remediation steps and is evident in the CVSS score itself. Ex: http://www.kb.cert.org/vuls/id/948155 “…the attacker would need network access to the database in order to obtain sensitive patient information.”
Please correct it immediately and ensure any other entities that receive a feed from your site also have corrected this misrepresentation. I will make our security response team aware of this posting and we will follow up with you tomorrow to ensure its corrected.
Please consider the environment before printing this email.
E-mail messages may contain viruses, worms, or other malicious code. By reading the message and opening any attachments, the recipient accepts full responsibility for taking protective action against such code. Henry Schein is not liable for any loss or damage arising from this message.
The information in this email is confidential and may be legally privileged. It is intended solely for the addressee(s). Access to this e-mail by anyone else is unauthorized.
Subsequent to this email, we had two comments left on other entries meaning the problem with comments causing a 500 are intermittent. Regardless, email is always a better way to ensure reaching us to discuss an issue.
From: Brian Martin
Cc: Legal @ OSF, OSVDB Moderators
Date: Fri, 17 May 2013 12:16:04 -0500 (CDT)
Subject: Re: [OSVDB Mods] Legal issue and web site problem
On Fri, 17 May 2013, Cross, David wrote:
: 1) When clicking on comment the web site returns a 500 error. As a
: result comments are not allowed on VBD items and owners of the software
: are not able to dispute misrepresentations in the posts.
Please note that in emailing the moderators, you are in fact disputing the
entry. This is a faster and more reliable method of raising a question
with us. During a recent upgrade, the comment functionality broke, and you
are the first to notice. That is why it has remained unfixed, as it is
considered very low priority to us.
: 2) Contains a fundamental misrepresentation of the original CERT
: posting which we will dispute with any and all means necessary. Please
: correct the post to indicate that the issue is not remotely exploitable
: which is clearly evident in the CERT post description, the remediation
: steps and is evident in the CVSS score itself. Ex:
: http://www.kb.cert.org/vuls/id/948155 “…the attacker would need
: network access to the database in order to obtain sensitive patient
Between your subject line calling this a “legal issue” and including “any
and all means necessary” in the body, the Open Security Foundation (OSF)
is considering this email a threat of intended legal action and will reply
accordingly. We already strive for accuracy in our data and have a long
history of going out of our way to ensure it, frequently contacting
vendors for additional information, bringing issues to their attention,
and engaging in emails such as this to figure out details.
First, our entry does not misrepresent the CERT posting at all. Looking at
CERT VU 948155, specifically the Solution section:
Restrict Network Access
As a general good security practice, only allow connections from trusted hosts and networks. Restricting access would prevent an attacker from using the hard-coded credentials from a blocked network location.
Do not allow the Dentrix G5 database to be accessed by unauthorized users on an insecure wireless network. If the Dentrix G5 database is accessible from an insecure wireless network, a remote attacker may be able to gain access using the hard-coded credentials.
Further, looking at the CERT page that includes what they call a “vendor
statement”, implying it came from Henry Schein Practice Solutions:
It is important to note, however, that the disclosure of the internal database password only posed a vulnerability for practices whose network was unprotected (i.e. practices who lacked a firewall and/or other basic network safeguards).
Between CERT and your company statement, it is abundantly clear that our
classification of this issue is accurate. In both cases, it explicitly
says that this may be a remote issue, and it relies on having third-party
hardware and software installed to protect the database from a remote
attacker. While most companies would follow these guidelines as part of a
regular security posture, we cannot make that assumption because history
has shown us that companies routinely fail to practice the most basic of
security measures. Our entries are added and updated with _factual
information_ pertaining to the issue. We do not account for network
configurations or the possible presence of third-party devices because
that does not happen 100% of the time.
With that, I have updated the entry to reflect that Henry Schein Practice
Solutions stresses that proper network protection be implemented to help
mitigate this issue. It does not change the fact that this can be remotely
exploited in some circumstances.
: Please correct it immediately and ensure any other entities that receive
: a feed from your site also have corrected this misrepresentation.
Now that the information is updated in our site, anyone viewing or
accessing the information has the latest updates.
: I will make our security response team aware of this posting and we will
: follow up with you tomorrow to ensure its corrected.
Likewise. I have made the other moderators aware of this situation and I
will be authoring a blog post on this entire matter (which will also be
Tweeted to our followers, and included on the ISN mail list that goes out
to ~ 6,000 security professionals), including the implied threat of legal
action to be posted Monday during business hours. We feel it is important
for the industry to know when a vendor uses such tactics in an attempt to
stifle vulnerability disclosure, and to unfairly pressure an organization
into displaying inaccurate information, which you are attempting to do.
OSF / OSVDB.org
Back in January, I issued a challenge to see how many new vulnerabilities would be entered into OSVDB over a three-month period. January went by, then February, and then March came and went. For anyone out there keeping score, here’s March’s totals:
2010-03-01: 32 vulns pushed, 164 vulns updated
2010-03-02: 27 vulns pushed, 149 vulns updated
2010-03-03: 9 vulns pushed, 73 vulns updated
2010-03-04: 53 vulns pushed, 207 vulns updated
2010-03-05: 17 vulns pushed, 94 vulns updated
2010-03-06: 9 vulns pushed, 56 vulns updated
2010-03-07: 4 vulns pushed, 103 vulns updated
2010-03-08: 25 vulns pushed, 125 vulns updated
2010-03-09: 42 vulns pushed, 157 vulns updated
2010-03-10: 24 vulns pushed, 243 vulns updated
2010-03-11: 7 vulns pushed, 64 vulns updated
2010-03-12: 52 vulns pushed, 148 vulns updated
2010-03-13: 4 vulns pushed, 15 vulns updated
2010-03-14: 2 vulns pushed, 43 vulns updated
2010-03-15: 18 vulns pushed, 136 vulns updated
2010-03-16: 77 vulns pushed, 232 vulns updated
2010-03-17: 31 vulns pushed, 277 vulns updated
2010-03-18: 48 vulns pushed, 458 vulns updated
2010-03-19: 3 vulns pushed, 224 vulns updated
2010-03-20: 25 vulns pushed, 100 vulns updated
2010-03-21: 3 vulns pushed, 222 vulns updated
2010-03-22: 18 vulns pushed, 101 vulns updated
2010-03-23: 0 vulns pushed, 60 vulns updated
2010-03-24: 5 vulns pushed, 20 vulns updated
2010-03-25: 39 vulns pushed, 162 vulns updated
2010-03-26: 38 vulns pushed, 245 vulns updated
2010-03-27: 40 vulns pushed, 95 vulns updated
2010-03-28: 18 vulns pushed, 41 vulns updated
2010-03-29: 14 vulns pushed, 329 vulns updated
2010-03-30: 46 vulns pushed, 413 vulns updated
2010-03-31: 44 vulns pushed, 341 vulns updated
2010-04-01: 63 vulns pushed, 397 vulns updated
Yes, we missed a day on the 23rd, but there’s a good excuse there. It was the following Tuesday after St. Patrick’s Day, which is usually around the time my hangover wears off and I realized that food and sleep are “good things”, so I took a day off. I think. If you have any evidence that I was conscious on March 23, mail me. Just curious.
Anyway, there you go. Over the course of the challenge, we promoted 2,060 new vulnerabilities into OSVDB, and as promised, I’ll be donating $1,030.00 to the Open Security Foundation. Extra special thanks go to all of the moderators and manglers who made it happen; you have no idea how much time and effort they all spent to get these vulnerabilities into the database. Now that the challenge is over, anybody out there who would like to match the challenge, even on a fractional basis (such as 25% of the amount donated), please contact us here and we’ll provide details.
Back in early January, I issued a challenge to donate to OSF’s Winter Fundraiser for every new vulnerability pushed into OSVDB. Two of the three months have come and gone, and even though January was a little more productive than February in terms of new vulnerabilities, the moderation team is still making good progress:
2010-02-01: 13 vulns pushed, 133 vulns updated
2010-02-02: 31 vulns pushed, 79 vulns updated
2010-02-03: 25 vulns pushed, 145 vulns updated
2010-02-04: 21 vulns pushed, 31 vulns updated
2010-02-05: 25 vulns pushed, 153 vulns updated
2010-02-06: 8 vulns pushed, 76 vulns updated
2010-02-07: 3 vulns pushed, 278 vulns updated
2010-02-08: 27 vulns pushed, 64 vulns updated
2010-02-09: 47 vulns pushed, 159 vulns updated
2010-02-10: 37 vulns pushed, 160 vulns updated
2010-02-11: 16 vulns pushed, 59 vulns updated
2010-02-12: 27 vulns pushed, 128 vulns updated
2010-02-13: 10 vulns pushed, 51 vulns updated
2010-02-14: 4 vulns pushed, 112 vulns updated
2010-02-15: 12 vulns pushed, 81 vulns updated
2010-02-16: 23 vulns pushed, 181 vulns updated
2010-02-17: 28 vulns pushed, 235 vulns updated
2010-02-18: 25 vulns pushed, 119 vulns updated
2010-02-19: 43 vulns pushed, 261 vulns updated
2010-02-20: 11 vulns pushed, 126 vulns updated
2010-02-21: 2 vulns pushed, 34 vulns updated
2010-02-22: 3 vulns pushed, 64 vulns updated
2010-02-23: 41 vulns pushed, 221 vulns updated
2010-02-24: 37 vulns pushed, 112 vulns updated
2010-02-25: 15 vulns pushed, 138 vulns updated
2010-02-26: 17 vulns pushed, 146 vulns updated
2010-02-27: 9 vulns pushed, 17 vulns updated
2010-02-28: 8 vulns pushed, 24 vulns updated
With 568 new vulnerabilities pushed in February, we’re now up to 1,223 new entries for 2010; personally, I’d like to see that number hit at least 2,000 by the end of March (3,000 may be out of reach, but never say never), but that will depend on the time and efforts of our moderation team and the amount of vulnerabilities uncovered by our multiple reference sources. Please remember that I will donate $0.50 to OSF for every new vulnerability pushed into the database through April 1 (and no, there will not be an April Fools announcement saying that the challenge has been called off), and we’re hoping to obtain some matching offers to help offset the costs of maintaining the database. A special “thank you” goes to all parties who have offered to match the challenge so far, and we hope others who find OSVDB to be a valuable resource can jump in and help us out as well.
31 more days for the challenge… and away… we… go.
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.
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:
- 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.
- 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.
- 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.
- 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.
- 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.
Results of Mangle-A-Thon 2009
Mangle-A-Thon 2009 went very well. In addition to some 20 or so primary sources matched for DataLossDB, several volunteers managed to improve the “complete-ness” of OSVDB by over a tenth of a percent. That may not sound like much, but with over 58 thousand vulnerabilities in that database, a tenth of a percent (0.1% for you math types) is a huge help.
We would like to send an enormous “Thank You!” to all those who came and helped out. You did a service to the entire industry by lending your time and efforts. Another enormous “Thank You!” to Midnight Research Labs Boston for hosting the event. The venue was perfect, and your efforts both in planning the event, and contributing at the event were invaluable. Thanks again to Voltage Security for sponsoring the event and providing the food and drink; it made the 12+ hours achievable.
We would like to extend one last “Thank You!” to all those who not only mangled at the event, but went home and have since mangled some more. That is exactly what we had hoped for: a community contribution by and for the security community, and we hope you enjoyed the experience and will continue to work with us.
The success of the event may drive us to do another one (probably not until next year), maybe in a different city, or it might just and up right where we did it this time. Maybe we’ll have it happen across a couple cities next time! Let us know what you think… any suggestions are welcome!
Join OSF in Somerville, MA on September 19th, 2009 from 8am to midnight for Mangle-A-Thon, and help us mangle vulnerabilities into the Open Source Vulnerability Database (OSVDB), and mangle data loss incidents and primary sources into the DataLossDB.
The event, hosted by Midnight Research Labs Boston, is free and sponsored by Voltage Security, which will assist us in providing food and drink for attendees. OSF moderators will walk participants through the projects and teach participants how volunteers maintain the entirety of both data sets. Our goal is to get as much new and accurate data into both databases as possible, possibly add a couple of new recruits into the fold, and have a good time doing it.
Have suggestions regarding the projects? The lead developer (Dave) will be there, as will lead content guys for both projects (Kelly and Craig). You can actually see your suggestions implemented right there at the event… but only if you attend. :)
Midnight Research Labs Boston
30 Dane Street
Saturday, September 19th, 2009
8am to midnight
(three time slots: 8am – 1pm, 1pm – 6pm, 6pm – midnight, register for all or some)
Register via the “Register” link at: http://mangleathon.opensecurityfoundation.org/
Like many nights, Jericho and I had a conversation. Unlike many nights, this one might actually be of interest to someone other than us (this pertains to how OSVDB gets new data into queue):
jericho (6/16/2009 8:48:48 PM): Original Advisory: FEDORA-2009-5368
Lyger (6/16/2009 8:48:57 PM): so just need to bump the scrape down a line
Lyger (6/16/2009 8:50:32 PM): takes an extra 10 seconds per vuln
Lyger (6/16/2009 8:50:39 PM): but multiply by 100
Lyger (6/16/2009 8:50:43 PM): adds up
jericho (6/16/2009 8:50:56 PM): yep
jericho (6/16/2009 8:51:09 PM): “only takes a second”
jericho (6/16/2009 8:51:16 PM): this was when i averaged 100 ndm a day
Lyger (6/16/2009 8:51:32 PM): 10 seconds, 20 vulns a day for me…
Lyger (6/16/2009 8:51:43 PM): three minutes per day
Lyger (6/16/2009 8:51:51 PM): 20 minutes a week
Lyger (6/16/2009 8:51:58 PM): 1.5 hours a month
Lyger (6/16/2009 8:52:00 PM): etc etc
Think about that: something that “only takes a second” seems somewhat insignificant in a single instance, but when you multiply it over days, weeks, months… years… the time adds up. To be honest, time is what we (OSF) have been fighting against for years. If we individually spend an extra ten seconds working on one vulnerability, just to add references or classifications, no big deal, right? But then you might see that if we work on 20 or 30 a day, that’s an extra 4 or 5 minutes a day, about an extra 30 minutes a week, around two hours a month, and approximately one day out of a year.
Personally, I’d like to have my day back (when I can get it, preferably somewhere in Hawaii and on the OSF dime).
For quite a while, we’ve been asking for volunteers to spend maybe even 15 minutes a week on this project. That would add up to an hour a month, and multiplying that by even 10 solid hardcore volunteers (or 50 occasional ones) would be amazing. They would get no pay and no benefits, but maybe a t-shirt, a “thank you”, and a feeling of giving something back to the security community. All for even 15 minutes a week…
Or about two minutes a day…
Open Security Foundation Wins the SC Magazine 2009 Editor’s Choice Award
Festivities in San Francisco wrapped up last night, and OSF was presented with SC Magazine’s 2009 Editor’s Choice Award. Thanks to everyone who has supported OSF in the past and present, and we definitely hope you’ll continue to support us in the future!