Follow @Openwall on Twitter for new release announcements and other news
[<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.