[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-id: <A15D21C2-8546-463B-8CBF-B87D5ECA12DE@mac.com>
Date: Mon, 25 Jul 2011 15:39:15 -0400
From: Jeff Johnson <n3npq@....com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE Request -- rpm -- Fails to remove the SUID/SGID
bits on package upgrade (RH BZ#598775)
There were a series of CVE's applied (and some withdrawn) against
whatever happens to be called "rpm".
The patch here was dropped when RPM was forked and the CVE was
essentially a replay of an issue that was already fixed 5 years ago
(and the patch was NOT dropped in @rpm5.org cvs).
(aside)
I believe there are better fixes if the link count is more carefully
checked always and everywhere. While rpm package metadata does not
(and SHOULD not) carry an expected value for st->st_nlinks, its
rather easy to synthesize an expected link count given the inode
information (which is in rpm metadata) and to warn (either with --verify,
or perhaps always) if the link count is not as expected.
There are other (and better) approaches if the actual values on
the file system, including files not contained in packages, is
stored in an rpmdb: its a fundamental design flaw in RPM that
only package metadata installed in an rpmdb is ever used
for security auditing.
But there's no harm at all in removing SUID/SGID bits from files that are being
removed in case there's an additional link that has been added.
hth
73 de Jeff
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
