Re: Security Errata not covering all versions of RHEL packages
inode0 <[email protected]>
| Newsgroups | gmane.linux.redhat.rhn.user |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Apr 2, 2008 at 1:52 PM, Josh Bressers <[email protected]> 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