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."

Running on PostgreSQL, too...

...per the database info [osvdb.org] page.

<shameless>
Hey OSVBD folks, here's a little utility to do do some PostgreSQL query analysis [rubyforge.org]!
</shameless>

Naming is important

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

Old news

Not the project, just the posts. Sendmail vulnerability from 2002? FreeBSD vulnerability (top of the list, no less) from 2000? Did I miss something?

Re:Old news

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.

Re:Old news

Not really - it's hard to take, but there really are systems out there who still haven't patched these vulnerabilities!

securityfocus

is'nt securityfocus doing that already?

Not really.

But CERT certainly has been.

They forgot one. . .

Slashdotting. ;)

Mmmmm....

No vendor spin on security issues. Now we can know the truth to the best of our ability without corporate FUD, hype or downplay.

Gotta love technology when it helps get the full-truth out there.

Can hear MS from here

I can hear it from here... Microsoft saying "See, Open Source isn't more secure than our stuff... there is a public database that all hackers and crackers can use to exploit known vulnerabilities..."

How long will it take till they say that?

Re:Can hear MS from here

There is one out there.

It's called the Microsoft Knowledge Base [microsoft.com]

Yes, that's a joke

This is certainly a good thing.

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.

Good stuff

Even thought the site seems a bit slashdotted it looks interesting. Even the open information on how to exploit, even though I'd just love to even get a full article on what makes every exploit possible. I like understanding. However, looks interesting.

Cool!

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.

Slashdotted?

As it seems to be already /.ed here is the Google cache [66.102.9.104]

Oh, yeah, this'll be *real* useful

Yeah, this'll be *real* useful. A database with entries that become obsolete after eight hours. "There's a Linux kernel vulnerability, and it...aw, darn." ;-)

Re:Oh, yeah, this'll be *real* useful

"There's a Win 3.11 vulnerability, and ... wow, it's listed as a feature in XP."

Re:Oh, yeah, this'll be *real* useful

Yeah, this'll be *real* useful. A database with entries that become obsolete after eight hours. "There's a Linux kernel vulnerability, and it...aw, darn." ;-)

Why would the data become obsolete after 8 hours? Not everyone runs out and installs the latest version of something for the hell of it you know.

Re:Oh, yeah, this'll be *real* useful

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.

Re:Oh, yeah, this'll be *real* useful

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.

Disagree

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.

Re:Disagree

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.

You miss the point.

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.

Those poor moderators!

Kudos to the OSVDB crew!
I wish you much success on completing your vulnerability update/addition modules so that your moderators' inboxes can have some breathing room!

With Retina [eeye.com] at $995 for 16 IP's, this additional gunpower for OSS will really keep the commercial vendors on their toes.

Maybe this will create a better turn-around time for M$'s "Security Initiative" too... Oh, wait, it's 4/2!

Open Source Vulnerability Database Goes Live...

Open source vulnerability database goes live...and two days later, it goes dead.

Slashdot - bringing you customizable DDoS attacks for years to come.

Professionalism

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.

Charts

I sure hope they will provide nice charts with statistics like which OS is more secure. Or perhaps a toplist with an approximation of how many users are affected. That would be very useful to the (h|cr)acker community. ;-)

already been done

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/

Re:already been done

The CVE is "A Dictionary, NOT a Database" of vulnerabilities. It appears you aren't familiar with the CVE

You would be better off to compare the OSVDB against the ICAT metabase [nist.gov]

The ICAT has some serious shortcomings which makes my work a big PAIN! (try to cross reference a specific vulnerability that matches 10 vulnerabilities).

OSVDB appears to better personify the open source paradigm in general, as such, I'd like to extend a warm welcome.

We expect great things from you.

Finally == Security Focus BIASED as hell

Security Focus became BIASED as heel from when Symantec bought them. Finally a really neutral source of information. Thank you for doing this guys ...

Checklist

what about security checklists, are there any? I mean when making a fresh install, after aplying all patches, what settings should be changed? For example restrictanonumous or nolmhash in WinXP, stuff like that.

A good idea

Is it a good idea to have a one-stop shop for potential crackers out there? Do the benefits really outweigh the fact that it's just gotten a hell of a lot easier to find a vulnerability in someone's server?

New update to nessus please

Nessusing their site right now is missing something that it definately should have reported.

Vulnerability to Slashdotting DDoS: High.

Well... I guess they just got their first bug

"The web server behind http://www.osvdb.org doesn't handle high traffic well enough".

oval.mitre.org

Yunz may want to look at http://oval.mitre.org
In addition to listing WHAT the vulnerability is,
it tries to define standardized methods for determining
HOW to test for it.

What makes this database "open source" ?

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 [osvdb.org] 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. [digitaldefense.net], 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 [wikipedia.org] out there...the precedent exists for high quality, truly FREE content. I hope OSVDB considers licensing the content under the GFDL or BSD license.

Canned Quote

Here is the canned quote, bereft of a single soundbite, which goes to show just how important this deal is to the company.

"This agreement will be of significant benefit to both Sun and Microsoft customers. It will stimulate new products, delivering great new choices for customers who want to combine server products from multiple vendors and achieve seamless computing in a heterogeneous computing environment. We look forward to this opportunity - it provides a framework for cooperation between Sun and Microsoft going forward."

McNealy went on saying "Microsoft is our ally. We have never been at war with Microsoft."

Does the concept of MS and Sun playing well with one another worry anyone else out there?

Easy livin'

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.

No 'sort by date'?

Am I the only one that likes browsing entries by the order in which they were created?

This wont last long

Expect them to be taken down soon due to a law suit

Not very complete.

The content is rather small with only 1878 entries. The ICAT [nist.gov] database, however, is mature with 6548 entries.

Interesting project, but it has some problems...

I like the idea behind this project, but there are a couple of problems here:

1) They don't provide an easy way fo downloading the database. You have to accept their license to download it before getting the real thing. ICAT and CVE Mitre don't put such restrictions to use their databases.
2) The database schema is made for PostgreSQL: This is cool and all, but I don't wanna be tied or tie my tool with a particular database; What if I want to use MySQL or Sybase or Oracle or MSSQLServer?. They should allow you to download the data in a compressed format as XML or CVS and then you can tweak it in order to load it into your application. This is something I don't like about ICAT (they distribute their database in Access format). Mitre CVE on the other hand allows me to download the database in CSV format and (don't remember the organization) has made the CVE dictionary already in XML format.
3) Why they don't use the CVE numbers? Just what we need, another propietary numbering schema (just check how each vendor called their vulnerabilities). The whole Idea of Mitre CVE was to end that nigthmare. If you want to include a vulnerability, then why you don't propose it as a Mitre CAN, use it, and then if accepted it will become a proper CVE entry. Is the process too slow?

Hopefully they will fix this soon.

Vulnerability?

How long 'til the sophistication of the database and the sophistication of a virus merge at a point where we have a virus that can consult the database and implement the vulnerabilities documented within?

Or, more likely, how long 'til they publish a vulnerability that they have failed to protect against?

OSVDB Concerns

With the public exposure of the Open Source Vulnerability Database (OSVDB.org), there have been a few concerns and fallacies voiced about the project. This reply is to clear up a few points and address some of the issues posted on various forums.

* The name "Open Source" Vulnerability Database implies it will catalog open source software, not closed systems such as Windows.

- While the name may imply that, the database will catalog all types of vulnerabities regardless of operating system or vendor. The name was chosen to show that the information contained in it would be open source itself, and to reflect the contributors.


* Why are old vulnerabilities on the top of the list?

- The 10 most recent vulnerabilities displayed on the main page show the recent entries that were approved for the publicly viewable database. This list is not designed to show the last 10 vulnerabilities made public. On the "todo soon" list is to have an xmlrpc and RSS feed to distribute truly new entries.


* Isn't SecurityFocus/CERT/CVE/ISS already doing this?

- Yes and no. CVE is "Dictionary, NOT a Database" and "CVE should not be considered as a vulnerability database on its own merit" according to their site. While SecurityFocus, CERT and ISS both maintain VDBs, OSVDB intends to do things differently. This should provide another free resource for security professionals.

At this time, the database content is significantly less than other databases, but this is a long term project. The time it takes to sort through roughly 10,000 vulnerabilities, put them in a standard format and ensure the accuracy of the information is immense. OSVDB is looking for more volunteers who would like to help this process. Even now, the OSVDB contains hundreds of vulnerabilities that aren't found in any others. We strive to be as thorough as we are accurate.

Now that the technical details have been worked out, the process established, and we're ready to support public use, the database content is the immediate concern.


* Can't this database be used by hackers and crackers?

- Yes, but no more so than an archive of the Bugtraq or Full-Disclosure mail list (or a number of other mail lists). Vulnerability information is already public, and easy to access with search engines such as Google. Every vendor that maintains an archive of security advisories for their own product offers attackers the type of information to hackers. The information is not inherently evil, the person who uses it incorrectly is.


* VBDs "like this one have a habit of publicising vulnerabilities without telling the software authors first".

- While vulnerability researchers may not warn vendors, any unpublished vulnerability information obtained by OSVDB will be handled within a responsible disclosure policy. At no time will we publish information that has not been disclosed to the vendor and reasonable time provided for a solution.


* "I sure hope they will provide nice charts with statistics.."

- Generating detailed statistics on vulnerabilities is one of our short term goals. These statistics will hopefully help people to learn more about the types of vulnerabilities, their history and help better evaluate risk for deployed platforms.


* Why isn't the OSVDB licensed under GPL or another more commonly used license?

- The short answer is that we want to avoid having a commercial entity use the work of a volunteer staff to profit. GPL would not allow credit to be required and extensive research showed that we needed to create our own license for now. Hopefully, the project will gain some funding to seek legal counsel or a nice lawyer will donate time to consult on the license. The point is we want the data to be free, however, to ensure that proper credit is given to OSVDB and its contributors. The licensing we have established is designed to protect us from this scenario by requiring branding of the data as having come from OS

Re:Can't handle load

that isnt what a vulerability DB is. it's not a huge patch server. its a place you can goto to see if an error you found while messing with bash (and accidently get root access) 1. has been reported 2. if there is a work around and 3. report it if it is a. repeatable and b. not yet reported.

Re:IT Koan

Excellent! Added it to my sig :)