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."
...per the database info page.
<shameless>
Hey OSVBD folks, here's a little utility to do do some PostgreSQL query analysis!
</shameless>
The Army reading list
The name implied to me that it is only vulnerabilities in Open Source programs/systems that will be tracked, but reading the FAQ it seems to be that the database itself is open-source, and the database covers all systems. I think they could have named it better.
Simon
Physicists get Hadrons!
Slashdotting. ;)
How long will it take till they say that?
After 3 days without programming, life becomes meaningless
- The Tao of Programming
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/
This should be done for all types of software...Perhaps developers will be a little more careful with their codeing and end users will be able to see just how secure the software is before they commit to it.
As it seems to be already /.ed here is the Google cache
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.
Not really - it's hard to take, but there really are systems out there who still haven't patched these vulnerabilities!
you know i hate the company but it has already been done and is most likely a better DB.
the MITRE Common Vulerability and Exposures DB
http://www.cve.mitre.org/
"There's a Win 3.11 vulnerability, and ... wow, it's listed as a feature in XP."
Security Focus became BIASED as heel from when Symantec bought them. Finally a really neutral source of information. Thank you for doing this guys ...
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.
And what happens when it isn't being fixed? Vendors have shown time and time again that unless pressure is put upon them, security fixes have a very low priority. Full disclosure is the best method of increasing that priority.
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