Mailing List Archive

(sent this from the wrong account earlier, moderators please ignore the
previous post)

On Friday 19 July 2002 15:38, Chris Wysopal wrote:
> So would you use a non-profit database that was populated by the
> vulnerability reporters themselves? That is what I am proposing.

I just started a similar project. Have about two dozen volunteers and am
working on the first draft docs for schema, requirements, moderation, and
licensing. The domain/project name is osvdb.org, the goal is to provide a
community-run vulnerability database catering to the needs of system
administrators and security professionals alike. We were planning on doing
this earlier, even went so far as to hire someone to create a nice Oracle
schema, but lacked the time and urgency to do it until now.

One of the primary goals is to allow user feedback on vulnerabilities, such
as problems applying patches in a given environment or exploiting the bug on
a specific architecture. The submission process will have to be moderated,
moderators would be volunteers from the industry who would like to contribute
to something immediately useful. My company, Digital Defense, has commited
to populating the database with our own in-house data set, which should be at
least get the ball rolling. Much of the correlation work has already been
done, so integrating CVE/BID/Nessus/Snort references should be pretty far
along from the beginning. Licensing terms will probably be GPLv2, we want OSS
developers to be able to use exports from the database for their own tool
reporting. While I would like to prevent commercial scan-in-a-box companies
from abusing it, theres no licensing system I can think of that will prevent
that but still allow consultants to provide reports using the verbage.
Plagiarism is absolutely not allowed, only exception being quotes from the
Vendor pertaining to the product, and those must be noted as such.

Below is a mini-annoucement that was sent in reply to Jay's post on the
Nessus mailing list...

---

To: "Jay D. Dyson" <jdyson@treachery.net>
Date: Thu, 18 Jul 2002 03:53:24 -0500

On Wednesday 17 July 2002 17:47, Jay D. Dyson wrote:
> On 18 Jul 2002, Michel Arboi wrote:
> > Just curious: will they consider the Nessus community as "trusted
> > security researchers" or as a gang of dangerous terrorists?
> >
> > Should we ask them? Just like this?
>
> Yes and yes.
>
> I may catch hell for this, but I see the corporate community as
> not exactly having the Open Source world's best interests at heart. Just
> have a look at the sort of legislation and lobbying they carry out under
> the guise of "security." It's enough to make a body swear off computing
> forever...

After talking to a SF employee and reading the two announcements that were
sent out, this is the impression that I got:

Symantec is allowing the mailing lists and SF web site to be operated just
as
it was previously by the same people. Their disclosure policy only applies to
vulnerabilities *found* by them, it has no bearing whatsoever on the list
traffic or exploits on the web site.

The only piece I am worried about is whether not-quite-public-bugs, such as
those reported through the vuln-help list or during vendor coordination, will
be made known to "trusted security researchers" at Symantec before release.

Symantec could always change their mind later, making all of the above null
and void, but considering the dedication of the Security Focus staff and
their full-dislosure views, I am willing to give it a chance and see how
things work out. Regardless, the deal is not final until August sometime.

On another note, an open source vulnerability database project has been
started. This database will be filled and maintained by the community,
providing complete support for CVE, Bugtraq, Nessus, and Snort. We are still
in the design phase, gathering requirements from system administrators and
pen-testers alike, hashing out the table structure, and deciding where to
host it. Myself and a few of the DDI staff are going to populate it with what
we can, but once the interface is up and volunteers are found, it will be in
the hands of the community. The database will be exportable in a number of
different formats and can be included and used by open source security tools.
There may be some restrictions on commercial use (no sense keeping the idiots
in business), but those restrictions will have to be approved by the
community first. If you have any suggestions, ideas, questions, flames, or
just want to get involved; please email them to osvdb@digitaloffense.net for
the time being.

-HD

-------------------------------------------------------

We have just overhauled our cooperative vulnerability database
(fixing many bugs), adding an exploit section with IDS rules, and
modifying it to allow the use a moderation process instead of a
3-reviewer process. What is interesting about it is that anybody can
improve a record by working on a copy and submitting it so that it
will supersede the original. As a basis it imports CVE information
daily but it is not bound by it. One drawback to it is that
operational policies have not been clearly defined; another is that
there currently isn't enough information in it.

Please have a look; accounts are and will remain free. We will keep
working on it. Feel free to make suggestions too, for features or
operational policies. At this point, I would very much like to know
what else it would take for the community to get involved in it, and
I am willing to share the stewardship with interested individuals and
companies. It is publicly accessible at:

https://cirdb.cerias.purdue.edu/coopvdb/public/

Cheers,
Pascal Meunier
Assistant Research Scientist, CERIAS



At 4:42 PM -0400 7/19/02, Steven M. Christey wrote:
>Jay D. Dyson said:
>
>> Look, I have nothing against someone trying to make a buck. That
>> is the cornerstone of the capitalist system. What burns my biscuits is
>> that the monolithic security companies are not making this money off their
>> own efforts[1], but by leeching off the egalitarian contributions of those
>> who possess a skill set the businesses are not willing to pay for.
>
>With organizations like CERT/CC projecting 4,000+ vulnerabilities this
>year alone, the amount of research and quality-checking that is
>required to maintain a good vulnerability database is growing
>prohibitive, even if most of the vulnerabilities were discovered and
>announced by many people in the community.
>
>As suggested by others, a publicly maintained vulnerability database
>is a possibility, but it would need a large-scale community effort to
>populate and maintain, and there would be issues of quality control.
>
>Maintaining a vulnerability database also requires some different
>skills than vulnerability research or system administration:
>
>- a stronger emphasis on writing for multiple audiences (technical
> details and high-level summaries)
>
>- identifying different technical areas and finding/keeping skilled
> people to cover them (e.g. crypto, Linux kernels, CGI, programming
> languages, etc.)
>
>- defining what will be in the database (this was an issue in the
> early days of CVE because everyone has different definitions of
> "vulnerability," and it's still an issue to some degree)
>
>- ironing out details like workaround and fix information (even
> determining whether the vendor has fixed the problem can be a
> challenge; researcher-suggested patches can be broken; some
> workarounds aren't feasible)
>
>- trying to distinguish between closely related vulnerabilities (is
> there one vulnerability or two? Did vendor X and Y really fix the
> same issue? Did vendor W's fix really address researcher Z's report
> from two months earlier?)
>
>- deciding on a severity metric (IMHO, high/medium/low must die)
>
>- getting consistent terminology (your XSS is not my XSS (or CSS)!
> Same with remote/local, directory traversal, etc.)
>
>- ensuring accuracy of information (which is sometimes problematic
> even in "full disclosure" instances)
>
>- actually validating whether the reported vulnerabilities are real or
> not (a daunting challenge for anything but the most commonly
> deployed products and configurations)
>
>- then designing, implementing, and maintaining the databases and the
> server(s) that support it.
>
>
>
>Chris Wysopal said:
>
>>Even so a completely non-corporate and free vuln database would be
>>something good for the community.
>
>NIST's ICAT database (http://icat.nist.gov) is freely available for
>download. It is built on top of the CVE list. Unfortunately, that
>means that some of CVE's challenges pose difficulties for ICAT,
>e.g. with respect to CVE's delays in making candidate numbers
>available after an issue has been disclosed. (BTW, we're focusing on
>improving our timeliness, which should improve noticeably in the
>coming months.)
>
>
>If everyone is serious about building and maintaining their own open
>vulnerability database, then consider using the following resources:
>
>1) Working group reports from the 2nd vulnerability database workshop
> at Purdue CERIAS, January 1999, especially the appendices.
>
> There is some good discussion regarding issues in creating "open"
> or "federated" vulnerability databases.
>
> http://www.cs.purdue.edu/coast/papers/99-06.ps
>
> (Google offers this file in text format, but the document structure
> is lost a little. http://citeseer.nj.nec.com/meunier99final.html
> may provide alternate formats)
>
>2) Purdue CERIAS has done some followup work in trying to create a
> public vulnerability database.
>
> "Sharing Vulnerability Information using a Taxonomically-correct,
> Web-based Cooperative Database"
>
> https://www.cerias.purdue.edu/papers/archive/2001-03.pdf
>
>
>
>Steve Christey
>CVE Editor

--
Pascal Meunier, Ph.D., M.Sc.
Assistant Research Scientist,
CERIAS
Purdue University

> Message: 6
> Date: Fri, 19 Jul 2002 16:42:13 -0400 (EDT)
> From: "Steven M. Christey" <coley@linus.mitre.org>
> To: full-disclosure@lists.netsys.com
> Subject: [Full-Disclosure] Creating a publicly maintained vulnerability
database
> Reply-To: full-disclosure@lists.netsys.com
>
> With organizations like CERT/CC projecting 4,000+ vulnerabilities this
> year alone, the amount of research and quality-checking that is
> required to maintain a good vulnerability database is growing
> prohibitive, even if most of the vulnerabilities were discovered and
> announced by many people in the community.

as usual, Steve hit the nail smack on the head. back when i owned (and
almost
singlehandedly maintained) PacketStorm (PSS), i only had to deal with a few
hundred vulns/year. i put in 80+ hour weeks, but i got it done (for the
most
part). now, with the number of vulns reaching 4000+ per year, it really
does
take a team of highly skilled researchers to maintain a vuln db. i know
exactly
what kind of people it takes, and i know just how interesting (and boring)
the
work can be, because i am currently spending about 180% (70+ hrs/wk) of my
salaried time maintaining vuln dbs and managing a team that researches and
validates vulns.

> As suggested by others, a publicly maintained vulnerability database
> is a possibility, but it would need a large-scale community effort to
> populate and maintain, and there would be issues of quality control.

maintenance and quality control become huge issues when you have to process
4000+ vulns/yr. finding people who know what gdb is AND spell correctly
AND
can legally work in the US AND are willing to work for less than
$160,000/yr
AND show up for work every day AND can pass a simple background check can
also be a challenge.

> Maintaining a vulnerability database also requires some different
> skills than vulnerability research or system administration:
>
> - a stronger emphasis on writing for multiple audiences (technical
> details and high-level summaries)

and if you want a really useful vuln db, you need both tech details and
hi-level summaries.

> - identifying different technical areas and finding/keeping skilled
> people to cover them (e.g. crypto, Linux kernels, CGI, programming
> languages, etc.)

and you have to have this too if you actually want the content in your vuln
db to be validated. and what good is the vuln db if the content is NOT
validated??? i have yet to see a single attempt at a public vuln db that
contains VALIDATED CONTENT. CVE comes closest (the content is very well
validated), but it is of course a vuln dictionary rather than a vuln
database.

> - defining what will be in the database (this was an issue in the
> early days of CVE because everyone has different definitions of
> "vulnerability," and it's still an issue to some degree)

and being the perfectionist that i am, i want ALL of it in the db.

> - ironing out details like workaround and fix information (even
> determining whether the vendor has fixed the problem can be a
> challenge; researcher-suggested patches can be broken; some
> workarounds aren't feasible)

and if the vuln db is going to really be useful, you will make sure to have
all of the patch info, the vendor info, the 3rd party patches, and the
workarounds. different people are going to need different solutions.

> - trying to distinguish between closely related vulnerabilities (is
> there one vulnerability or two? Did vendor X and Y really fix the
> same issue? Did vendor W's fix really address researcher Z's report
> from two months earlier?)

stop it Steve! my head already hurts without your mentioning this.

> - deciding on a severity metric (IMHO, high/medium/low must die)

and training all of the people who maintain your database to fully
understand and consistently apply that metric is another issue.

> - getting consistent terminology (your XSS is not my XSS (or CSS)!
> Same with remote/local, directory traversal, etc.)
>
> - ensuring accuracy of information (which is sometimes problematic
> even in "full disclosure" instances)

independent validation is the only good answer, and this will consume
89.54% of your time.

> - actually validating whether the reported vulnerabilities are real or
> not (a daunting challenge for anything but the most commonly
> deployed products and configurations)

especially tough if you are a small, public, non-profit org and you don't
have the $$$ to purchase the technology affected by the vuln (and the
vendor
won't give you a copy - not even an eval copy that may be different from
the
full licensed version mentioned in the original vuln advisory).

> - then designing, implementing, and maintaining the databases and the
> server(s) that support it.

seems like many of the private, for-profit databases focus on this aspect,
at the expense of the content. imo, the container is entirely useless if
the content isn't there.

> Chris Wysopal said:
>
> >Even so a completely non-corporate and free vuln database would be
> >something good for the community.
>
> NIST's ICAT database (http://icat.nist.gov) is freely available for

---[snipped stuff about icat and cerias]---

unfortunately, neither of those projects has offered a truly comprehensive
and timely vuln db yet. until and unless some benevolent entity provides
big $$$ to fund such an endeavor, i doubt we'll be seeing a quality,
comprehensive (i want exploit code too!), *validated*, public vuln db any
time soon. ICAT ain't bad though - need to be more timely and provide more
info for each vuln.

> Steve Christey
> CVE Editor

if i burn out and have to retire to the beaches of n. san fran, i will be
calling Steve and asking him to be my sponsor at Vulnerabilities Anonymous.

Regards,
kw

Ken Williams ; CISSP ; Technical Lead ; CVE Editorial Board
eSecurityOnline - an eSecurity Venture of Ernst & Young
ken.williams@ey.com ; www.esecurityonline.com ; 1-877-eSecurity



________________________________________________________________________
The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Ernst & Young LLP