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!
Not the project, just the posts. Sendmail vulnerability from 2002? FreeBSD vulnerability (top of the list, no less) from 2000? Did I miss something?
is'nt securityfocus doing that already?
Slashdotting. ;)
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.
Even if I knew that tomorrow the world would go to pieces, I would still plant my apple tree. -Martin Luther
How long will it take till they say that?
After 3 days without programming, life becomes meaningless
- The Tao of Programming
But CERT certainly has been.
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/
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.
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
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." ;-)
May we never see th
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.
I think the open-source that you speak of isn't invulnerable.
I wish you much success on completing your vulnerability update/addition modules so that your moderators' inboxes can have some breathing room!
With Retina 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!
-- In Soviet Russia, radio listens to YOU!
Open source vulnerability database goes live...and two days later, it goes dead.
Slashdot - bringing you customizable DDoS attacks for years to come.
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
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. ;-)
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/
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.
Security Focus became BIASED as heel from when Symantec bought them. Finally a really neutral source of information. Thank you for doing this guys ...
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.
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.
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?
Patriotism - the last resort of scoundrels.
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.
Nessusing their site right now is missing something that it definately should have reported.
Vulnerability to Slashdotting DDoS: High.
"The web server behind http://www.osvdb.org doesn't handle high traffic well enough".
You don't think enough... therefore you better not be!
How is this new database any different from LinuxSecurity.com? That site tracks several hundred vulnerabilities a week for all the distros (yes, buffer overflows and exploits and everything...stuff Slashdot doesn't ever report!)
Anything that's bad for open source, is good for the economy
1) Host mailing lists like Bugtraq.
2) Publish security papers a la SANS Reading room
and SF Infocus.
If they can do that and the open source community would start using these, then SF and SANS would
have some competition.
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.
If M$ made a database of all M$ vulnerablilities would M$ database software be good enough to handle it?
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.
I'm missing something here...
How is this different from cve.mitre.org? Seems like a re-invention of wheel.
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?
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
Am I the only one that likes browsing entries by the order in which they were created?
Expect them to be taken down soon due to a law suit
---- Booth was a patriot ----
The content is rather small with only 1878 entries. The ICAT database, however, is mature with 6548 entries.
Never ascribe to malice what can be adequately attributed to ignorance. -Napoleon
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.
Jose Vicente Nunez Zuleta RHCE, SJCD, SJCP
1. The Mitre CVE is "A Dictionary, NOT a Database".
2. The ICAT Metabase is seriously flawed, even more so than the CVE.
3. The Schema may be for PostgreSQL, but the contents should be ANSI SQL compliant. Gee, so hard?
4. Are you even familiar with the CVE or ICAT? I think not.
I don't know the original poster but...
:)
> 1. The Mitre CVE is "A Dictionary, NOT a Database".
What is your point here? Obviosuly you didn't bothered to read the poster original comments...
>2. The ICAT Metabase is seriously flawed, even more so than the CVE.
How come? Can you provide a concrete example?. Looks like flamebait here...
>3. The Schema may be for PostgreSQL, but the contents should be ANSI SQL compliant. Gee, so hard?
Still, why don't use a really neutral format?. You have XSLT that can convert to SQL if you want to and even better you can tweak the XML to fit it in your own customized database schema. The real value here is the data, not the database schema.!
>4. Are you even familiar with the CVE or ICAT? I think not.
You don't seem to know too much about that either
1. There is a reason for the restrictions, we want to make sure people know what they are before they download the data.
2. The backend uses various PGSQL stored procedures, but the data itself should be SQL99 compliant, porting it into a different database isn't hard. An XML server is in development, a CSV file would't work; the database is simply too complex for an entry to be displayed as a single line of text (multiple languages, dozens of text types, revisions, affected products and versions [ividivudally listed], etc). You may want to take a closer look at the content before making these recommendations.
3. CVE numbers *ARE* included for most vulnerabilities, however many of the entries have no corresponding CVE. CVE is not the end-all of security holes, it doesn't track quite a few things (common misconfigurations, etc) that may security products need to reference. Someone said this before, but CVE is a dictionary, not a database; it defines vulnerability types, not the vulnerabilities themselves. The OSVDB includes fields for things like web checks, administrator's notes, pen-testers notes, etc.
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?
once debian gets a non-crippleware installer, they will. K:}
If opportunity came disguised as temptation, one knock would be enough.
3^2 * 67^1 * 977^1
The Mitre CVE = a dictionary. It lists types of vulnerabilities. It is not a database that can be queried for specific instances of vulnerabilities, by OS, by application type, etc.
(Now you know what the CVE is, and isn't).
The NIST ICAT takes CVE numbers, and attempts to reference specific vulnerabilities against it. It tracks to a limited extent, OS type, application version, etc. The problem with the NIST ICAT is the generic terms that are used often, so one specific ICAT entry might match 5 different specific vulnerabilities.
(Now you know what the ICAT is, and isn't).
Want a test case? Take any piece of software that has had multiple vulnerabilities, sendmail for example. Now take the output of ICAT and attempt to match the vulnerability listed against specific problems. You'll be able to do about 50% of it easily. 25% more you'll be able to manage with some detective work. The other 25% will match multiple things and you will be unable to create a concrete match. The NIST ICAT is a step in the right direction, but because many of the vulnerabilities listed are written in a generic manner, PRECISE tracking is impossible.
(Now you know what the problem is with ICAT).
Now for a real world example:
You are tasked with doing an enterprise certification & accreditation effort for a government agency. They want to track their vulnerabilities across the entire organization as you report them. They are tracking their high risk vulnerabilities so they can allocate resources to fix them asap, while taking a more longterm perspective on minor vulns. They are your customer, and would like their vulns matched against ICAT..... You then run into problems then, matching the specific vulnerabilities against ICATs. It doesn't reflect greatly on the C&A effort (because ICAT matching is mainly a value-add).
ANSI SQL is a neutral format. It is the primary standard for Database SQL. I'd prefer to have it in ANSI SQL to some other format. I'm not part of the OSVDB team though, so why don't you ask them.
As for being familiar with the CVE/ICAT, it is obvious that I am. Next time before you accuse someone of trolling, research the subject at hand.
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