Slashdot Mirror
Open Source Vulnerability Database Goes Live
Alascom writes "The Open Source Vulnerability Database project has finally gone live. The project aims to provide comprehensive, free and unbiased (no vendor spin) vulnerability information. The database is being incorporated into such fine open source utilities as SNORT and NESSUS."
I could see many users getting angry over this, thinking this is to the disadvantage of open source technology, but no.... this is clearly an advantage! This database will help ensure that essential bug fixes get worked on immediately.
So don't flame over this... it will help make open source software more secure!Oh, right, and if you might think to the contrary, that people not knowing about vulnerabilities is the best way to go for security, you clearly need to do more research on the way open source software works, and why it is so effective.
http://mediagoblin.org/
I don't agree with "...vendors have this much time to patch..." I don't just disagree with it on this database, but all of them. That is just defeating the whole purpose. "We'll give you this long to fix it, and if not, we release our dogs!" That is inherently stupid, for lack of a better word. Regardless of the amount of time passed, the general public, or hacker public, does not need to know how to exploit these bugs, only that they exist, and are being fixed, and where to get the newest version. The vendors, sure, they need to know so they can fix it. It is a good idea, but hey, so is BT on securityfocus, and we all know how that has been abused.
Like spin and hype are a vendor monopol... Is OS spin really better ?
Spin is everywhere where there is subjectivity.
É que os desafinados também têm um coração
There's two conflicting maxims when it comes to updating systems:
'Always apply the latest updates' and 'If it ain't broke, don't fix it'.
Given that many people are both lazy and ignorant, they like to assume that if it appears to be working, it is, and thus they don't have to update/fix it. I imagine there's a lot of sendmail systems out there unpatched since before 2002. Old news, in terms of serious vulnerabilities, is therefore still highly relevant, since it provides a quick way of pointing and saying: 'Look, it is broken, fix it you lazy muppet'. :-)
Having said that, those are just the 'most recent entries' on the frontpage in relation to date of entry to the database. I think that's useful to have there so you know what's been added since a previous check.
I think that this is an excellent concept...I just wish that it were executed well enough that the site wasn't Slashdotted after 25 comments. I mean, damn, we're already trying to shake off the image of being a bunch of amateurs, and having a web site that can't even stand up to moderate traffic doesn't help.
How To Get Humans To Mars
A slashdotting is an honour, not a disgrace ;) The sistes of many commercial adventures have gone down after a couple of comments - hell, some have even gone down while the story is still in "The Distant Future" waiting for the front page. A slashdotting is nothing to be ashamed of.
Customers have a right to know that they are using vulnerable software, and be given the chance to secure themselves in any way possible. When I say customers, that means not only joe sixpack, but the admins of mission-critical and sensitive systems as well. If the vendor is unable or unwilling to fix the problem in a reasonable amount of time, the public should be given the ability to. Security through obscurity is a farce. Script kiddies might take exploit code once it is posted, but the crackers that otherwise know of these exploits are the ones doing the real damage.
Information can be abused, yes, but personally, I think it is better than ignorance.
It's unfortunate, however, that DBs like this have a habit of publicising vulnerabilities without telling the software authors first. IMO if you find a problem you should tell the software dev team, give them a chance to fix it and then publicise the vulnerability along with the patch, minimising the impact that crackers could have with the info.
I do agree that if the software developers are uncooperative then publicise the software problems, worst case scenario with OSS someone else can patch it. What irritates me is when people make a problem public without giving anyone a chance to get a fix out the door.
Calling something "open source" doesn't make it open or free (as in freedom). There are three issues of concern here.
First, the licensing terms Why didn't they license the OSVDB database under a free license, whether it be GPL, GFDL, or even the BSD license? If OSVDB and its sponsors (including primarily Digital Defense, Inc., a privately held computer security firm) retain complete ownership of the content, and nobody has the right to fork the database or create derivative works, I can't see why it's being spun as "open source".
Second, I was concerned when I read the OSVDB's statement of intent to comply with the DMCA. A non-free (read: non-forkable) database based in the United States might not be the best idea. One DMCA injunction could shut it down. Since, from my reading of the terms and conditions, nobody has the right to duplicate or fork this database, the work could not continue outside the US if a DMCA injunction shut it down.
Third, the issue of neutrality and bias. I don't believe that a non-free database sponsored by a private security consulting firm based in the United States will be able to remain neutral for long. Private companies are under no obligations to disclose their partnerships or agreements with vendors.
You know, there are non-trivial, free (GFDL) databases out there...the precedent exists for high quality, truly FREE content. I hope OSVDB considers licensing the content under the GFDL or BSD license.
Where's the OSVDB client, that I install on a host on my LAN, that gets up-to-date security notices selected from queries defined by my local configs? That is the missing layer in OSS SW distribution. Installers, like apt-get, should register installed packages with the local OSVDB.
The local DB gets queried by the client for installed inventory, queries the remote server. Vulnerable SW is tagged with advisory instructions, including patch URLs, confirmation URLs, and "help me" URLs, as well as the URL of the Internet site with that support and more (discussions, etc). The client sends a notification email to the sysadmin, optionally including clickable HTML to install the patch packages (which are, of course, registered with the local DB). Confirmation reports are easily entered in the HTML interface, pointing at the client, which first posts them to the local DB cache for later analyis, then posts them to the remote OSVDB. Requests for help are passed to tech support, based on a policy config'ed when the client is installed: existing support contracts, filtered marketplace pool, goverment/industry referral service.
This infrastructure is the natural evolution of the global infosystem. It mirrors the evolution of the cell: we've got a cell (fire)wall already, and the nucleus (sysadmin server) is now growing a membrane (security infrastructure), with tRNA codes (patches) keeping homeostasis (uptime). As the organism (network) is sickened (exploited) by viruses (viruses) and genetic defects (bugs), vaccines (patches) and therapies (upgrades) keep the organism healthy, and reduce the risk of epidemic infection (every few days on the Internet). Once organisms got an immune system, and communities that worked with it, we took over the world from the volcanoes, eventually freeing our brains for human endeavors (gaming, surfing porn, online dating). If developers bundle the straightforward complexity in simple automated tools, the infosystem's health will become as implicit as our own.
--
make install -not war
DBs like this have a habit of publicising vulnerabilities without telling the software authors first.
Seems like they could fill a niche need here by allowing people to report vulnerabilities, but not automatically posting them until a set time after the report date. Then having it automatically notify the vendor of the vulnerability. The vendor could ignore it (in which case after a set interval the issue would go public) or fix it and let it go public sooner.
Just a thought.
-Tom