[rhn-users] Security Errata not covering all versions of RHEL packages

inode0 inode0 at gmail.com
Wed Apr 9 05:44:27 UTC 2008


On Wed, Apr 2, 2008 at 1:52 PM, Josh Bressers <bressers at redhat.com> wrote:
>  >
>  > One shortcoming in the security offerings provided by Red Hat is an
>  > easy way to audit for known vulnerabilities in installed packages. The
>  > security plugin is a wonderful addition in this regard but still
>  > doesn't (or perhaps I just don't quite know how to use it yet) cover
>  > the case where there is a known vulnerability but no errata has been
>  > issued (or sometimes will ever be issued) for it.
>  >
>  > When a decision is made not to fix security issues in a package I
>  > would really like this to be documented somewhere so users like me can
>  > learn why and understand what I should or shouldn't do as a
>  > consequence of Red Hat's decision. Issuing something like WONTFIX
>  > errata would be something I'd very much like to see. It seems the only
>  > way to get this information now is to contact the Security Response
>  > Team directly and ask.
>  >
>
>  This information is currently captured via bugzilla and NVD.  We are
>  working on a better solution, but for the moment, you have to know how the
>  process works to get your answers.  As always, you can mail the Security
>  Response Team with questions.
>
>  We track all public CVE ids via bugzilla, assigning the CVE id to the bug
>  alias.  This means for example that if you wanted information regarding
>  CVE-2008-0887, you could issue this query:
>  https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2008-0887

I'm not really seeing how this is useful to me in general. For example, consider

https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2008-0005

While we get a hit there is no comment about RHEL versions of httpd
and I'm denied access to bz entries depending on this one.

Consider also

https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2007-5000

Again nothing about RHEL versions. Both of these were covered by

https://rhn.redhat.com/errata/RHSA-2008-0006.html

and related errata. I can tell from the errata released that all the
versions of apache that lived in the base channels were affected.
However if I am running another version of apache for example, which
did not have an errata released for it, I can tell nothing about
exposures to these vulnerabilities.

>  We tend not to include CVE ids for issues that don't affect Red Hat
>  products in bugzilla, so we issue NVD statements for that purpose.  For
>  example, there was recently a GnuPG flaw that did not affect Red Hat
>  Enterprise Linux (See the Vendor Statements section):
>  https://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-1530

So I go check

https://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-0005

and I see links from Red Hat for the various errata they released.
There is no information that I can find about any statement from Red
Hat describing affected packages that are supported by Red Hat but not
covered by those errata.

Statements that such and such a package is not affected are very nice,
but I want to know when such and such a package is affected and is not
being fixed and the reason for that decision. Typically those
decisions are made based on assumptions, and I want those assumptions
to be true if I am running a package with unpatched known
vulnerabilities.

Asking the customer to wade through 5 errata, notice that some
installed package wasn't covered by any of them, visit bugzilla and
NVD, throw up his hands and send you email is I think asking too much
from the customer.

If Red Hat chooses to leave some package unpatched, for reasons that
may be justifiable (incredibly low risk, not exploitable in default or
common configurations, etc.) I think Red Hat has an obligation to make
that decision known to customers using the affected packages - well,
really all customers. We might not be running them in a way that fits
your assumptions and we should be aware of the risk. The customer
should not need to recognize the danger and ask you, the customer
should be informed by you when you make such decisions (in my
dreamworld at least).

I really can't see why delivering a notification of this sort is any
harder than delivering an errata to me, unless the reason isn't
technical.

Thanks again Josh.

John




More information about the rhn-users mailing list