Hints for working with CVEs?

[Jason L Tibbitts III]

Does anyone have any notes for dealing with the CVE lists?  I know the
main access page is http://www.cve.mitre.org/cve/, but all you can do
is download the whole list or do a text search.  (And the whole list
in plain text is 15MB.)  I see that someone at Purdue offers change
lists, but the format is not terribly useful (just the numbers of the
changed entries).

Are there any tools that can extract useful summaries of this data
that we could use?  Even number and summary would be helpful.

For example, I know there's a recent clamav vulnerability that affects
Extras.  Now, I can search to find out that it's CVE-2006-1989.  I
know Enrico pushed 0.88.2 on May 2 so we're not vulnerable.

But, how would I have seen the CVE without knowing it existed?  Click
on every link in the daily changelogs and manually read the
description?  There has to be a more efficient way.

BTW, what would be the format of the line to add to the fe4 and fe5
files for this?

CVE-2006-1989 version (clamav, fixed 0.88.2)

(no bug number, no announcement obviously)

 - J<

[Dennis Gilmore]

On Friday 05 May 2006 10:05, Jason L Tibbitts III wrote:
>  For example, I know there's a recent clamav vulnerability that
> affects
>  Extras.  Now, I can search to find out that it's CVE-2006-1989.  I
>  know Enrico pushed 0.88.2 on May 2 so we're not vulnerable.
>
>  But, how would I have seen the CVE without knowing it existed?  Click
>  on every link in the daily changelogs and manually read the
>  description?  There has to be a more efficient way.
>
>  BTW, what would be the format of the line to add to the fe4 and fe5
>  files for this?
>
>  CVE-2006-1989 version (clamav, fixed 0.88.2)
>
>  (no bug number, no announcement obviously)
>
>   - J<
>  
When i saw this on bugtraq i first searched bugzilla.  which had no bug 
filled.  I then checked the repo  to see if packages were updated.  which 
they were not at that time. I then checked the fedora-extras-commits to see 
if  there was something there.  and the updates had been commited.  My 
question is  should I have filed a bug anyway  so that we have a public 
record  that the issue  had been fixed?


-- 
Regards

Dennis Gilmore,  RHCE
Proud Australian

[Jason L Tibbitts III]

> >>>> "DG" == Dennis Gilmore
> <dennis(a)ausil.us&gt; writes: 
DG> My question is should I have filed a bug anyway so that we have a
DG> public record that the issue had been fixed?

I think that there's no point in filing bugs about things which have
already been fixed, especially now when we're just getting started.
However, if the fixed package is not at your local mirror then you
should definitely open a ticket.

The fact that changes had been committed doesn't mean that a build was
requested, or that it has succeeded.  The packager may be unable to
request builds for whatever reason (which has happened before with
clamav; I ended up doing it).  The package could even be built and
sitting in the queue awaiting someone with the signing key to do their
thing.  (In the latter case, we should ping the list of package
signers, the name of which I have now forgotten but which needs to get
into the wiki ASAP.)

 - J<

[Josh Bressers]

>  >>>>> "DG" == Dennis Gilmore
> <dennis(a)ausil.us&gt; writes:
>  
>  DG> My question is should I have filed a bug anyway so that we have a
>  DG> public record that the issue had been fixed?
>  
>  I think that there's no point in filing bugs about things which have
>  already been fixed, especially now when we're just getting started.
>  However, if the fixed package is not at your local mirror then you
>  should definitely open a ticket.
>  
>  The fact that changes had been committed doesn't mean that a build was
>  requested, or that it has succeeded. 
This is a time the package-release tool can come in handy.  It will tell
you which versions of a package are available (not what's in CVS).  I
modified the tool last night to support fuzzy matching, so if I run
'package-release perl' I get a list of all packages with 'perl' in their
name.

-- 
    JB

[Jason L Tibbitts III]

> >>>> "JB" == Josh Bressers
> <bressers(a)redhat.com&gt; writes: 
JB> This is a time the package-release tool can come in handy.

It's also useful to check the completed package list in the build
system:

http://buildsys.fedoraproject.org/build-status/success.psp

If you see that a security-issue-fixing package has been built but
wasn't on the last package push announcement then you should bug the
signers.

 - J<

[Josh Bressers]

>  Does anyone have any notes for dealing with the CVE lists?  I know
> the
>  main access page is http://www.cve.mitre.org/cve/, but all you can do
>  is download the whole list or do a text search.  (And the whole list
>  in plain text is 15MB.)  I see that someone at Purdue offers change
>  lists, but the format is not terribly useful (just the numbers of the
>  changed entries).
>  
>  Are there any tools that can extract useful summaries of this data
>  that we could use?  Even number and summary would be helpful.
>  
>  For example, I know there's a recent clamav vulnerability that affects
>  Extras.  Now, I can search to find out that it's CVE-2006-1989.  I
>  know Enrico pushed 0.88.2 on May 2 so we're not vulnerable.
>  
>  But, how would I have seen the CVE without knowing it existed?  Click
>  on every link in the daily changelogs and manually read the
>  description?  There has to be a more efficient way. 
Nothing officially exists to do this.  I've been meaning to write one for
quite some time.  NIST has something similar to what you're looking for
here: http://nvd.nist.gov/

>  
>  BTW, what would be the format of the line to add to the fe4 and fe5
>  files for this?
>  
>  CVE-2006-1989 version (clamav, fixed 0.88.2) 
This is correct, yes.

-- 
    JB

[Jason L Tibbitts III]

> >>>> "JB" == Josh Bressers
> <bressers(a)redhat.com&gt; writes: 
JB> Nothing officially exists to do this.  I've been meaning to write
JB> one for quite some time.  NIST has something similar to what
JB> you're looking for here: http://nvd.nist.gov/

The small http://nvd.nist.gov/download/nvdcve-recent.xml file looks
reasonable; it's small, goes back a week or so, and should be easy to
parse.  Unfortunately I've not done XML parsing before so it would
take me a bit of time ti figure something out.

JB> This is correct, yes.

Thanks; I checked it in.  Is there any particular format used for the
cvs commit log?

 - J<

[Ville Skyttä]

On Fri, 2006-05-05 at 12:51 -0500, Jason L Tibbitts III wrote:

>  The small http://nvd.nist.gov/download/nvdcve-recent.xml file looks
>  reasonable; it's small, goes back a week or so, and should be easy to
>  parse. 
What kind of things would you like to produce out of that?  They have a
XML Schema available for the XML, which can be used to generate code for
various languages.

On the other hand, if the intention is to just transform that into a
human friendlier format (HTML, plain text), doing that with XSLT would
be pretty easy.

[Jason L Tibbitts III]

> >>>> "VS" == Ville Skytt <Ville> writes:
VS> What kind of things would you like to produce out of that?

A couple of ideas:

Produce a simple summary with one or two lines of text per entry that
could be scanned quickly by a human.

Fuzzy match the "prod name" against our list of packages.  Also use
the "vers" tags and the guts of our existing package-releases script
to see if we're vulnerable.

Unfortunately my knowledge of XML is so limited that I don't understand
how you'd use the schema to generate a parser, but I'll try to figure
that out.

 - J<

[Ville Skyttä]

On Sat, 2006-05-06 at 09:33 -0500, Jason L Tibbitts III wrote:
>  >>>>> "VS" == Ville Skytt <Ville>
> writes:
>  
>  VS> What kind of things would you like to produce out of that?
>  
>  A couple of ideas:
>  
>  Produce a simple summary with one or two lines of text per entry that
>  could be scanned quickly by a human. 
That sounds like something that could be done with XSLT.  See attachment
for a _really_ simple XSL, and run it like:

xsltproc nvdcve-recent.xsl http://nvd.nist.gov/download/nvdcve-recent.xml

>  Unfortunately my knowledge of XML is so limited that I don't
> understand
>  how you'd use the schema to generate a parser, but I'll try to figure
>  that out. 
Here's some pointers:
Java: http://xmlbeans.apache.org/
C++: http://codesynthesis.com/projects/xsd/
Python: http://www.rexx.com/~dkuhlman/generateDS.html

I've only used XMLBeans myself, the rest were found by quick Googling.
There are probably similar things available for other languages too.