 | | | how to verify a vulnerability is closed | how to verify a vulnerability is closed 2005-01-26 - By Ed Wilts
Back
On Wed, Jan 26, 2005 at 09:05:21PM +0100, nodata wrote:
> On Wed, 2005-01-26 at 14:59 -0500, Lloyd H. Meinholz wrote:
> > How would one go about verifying that patch for a vulnerability (ex. CVE
> > number CAN-2003-0693) has been back-ported on a RHEL3 system?
>
> If you're lucky, the CAN number will be referenced in a
> rpm -q --changelog packagename
Give the man a cigar!
[ewilts@(protected) ewilts]$ rpm -q openssh --changelog | grep -B3 CAN-2003-0693
* Tue Sep 16 2003 Nalin Dahyabhai <nalin@(protected)> 3.6.1p2-11
- apply patch to store the correct buffer size in allocated buffers
(CAN-2003-0693)
> > What has happened is that we have just had a security audit performed
> > and my RHEL3 systems show up as vulnerable to CVS number CAN-2003-0693
> > (a buffer overflow in openssh). Versions prior to OpenSSH 3.7 were
> > vulnerable. The latest OpenSSH package for RHEL3 is 3.6.1p2-33.30.3.
Many security audits are done by people who have no clue how Red Hat
applies patches. They simply do a version check like you've done and
not looked at the specific patch at all. In short, your security
auditor screwed up (at least you're asking the right questions!). If
the security auditors can't identify what's fixed, do you trust them to
identify what's not?
> > While I'm on the subject, it seems like it is more work to backport
> > features/bug fixes (then test) than to simply upgrade the package (then
> > test) and it seems like it would carry similar risk as simply upgrading.
> > Why is backporting considered more stable than backporting features?
http://www.redhat.com/advice/speaks_backport.html
--
Ed Wilts, RHCE
Mounds View, MN, USA
mailto:ewilts@(protected)
Member #1, Red Hat Community Ambassador Program
--
Taroon-list mailing list
Taroon-list@(protected)
http://www.redhat.com/mailman/listinfo/taroon-list
Earn $52 per hosting referral at Lunarpages.
|
|
|