|Summary:||CVE-2005-4889 rpm: Updates leave hardlinked copies untouched.|
|Product:||[Fedora] Fedora||Reporter:||Michael Schröder <mls>|
|Component:||rpm||Assignee:||Paul Nasrat <pnasrat>|
|Status:||CLOSED UPSTREAM||QA Contact:||Mike McLean <mikem>|
|Version:||3||CC:||jlieskov, mattdm, n3npq, pmatilai, vdanen|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-11-04 13:38:47 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||625756, 150222|
Description Michael Schröder 2004-06-08 13:57:07 UTC
If a malicious creates a hardlink to a buggy s-bit program the system is still compromised even after a fixed version has been installed. The attached fix removes the s-bits from files that get updated.
Comment 1 Michael Schröder 2004-06-08 13:57:40 UTC
Created attachment 100965 [details] Proposed patch
Comment 2 Matthew Miller 2005-04-26 16:37:56 UTC
Fedora Core 2 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC3 updates or in the FC4 test release, reopen and change the version to match.
Comment 3 Michael Schröder 2005-04-26 16:48:43 UTC
Hmm, good question. I leave it to your security group to decide if it's a security issue or not. For now, I've changed the product to FC3.
Comment 4 Matthew Miller 2005-04-26 17:59:40 UTC
Hmmm. I can see how that might be an issue. I'm going to clone this into Fedora Legacy as well as leaving in FC3. Thanks.
Comment 5 Paul Nasrat 2005-04-26 22:13:47 UTC
Adding security group and flag - will look at thanks.
Comment 7 Jeff Johnson 2005-11-04 13:38:47 UTC
This patch should probably be done in other ways, but is ok for what the patch does. Patch added to rpm cvs, should be in rpm-4.4.3-0.35 when built.
Comment 8 Michael Schröder 2010-06-02 13:00:58 UTC
(Argh, you didn't apply the chunk that removes the bits in the FSM_RENAME case! See bug #598775)
Comment 9 Jeff Johnson 2010-06-02 13:31:35 UTC
Created attachment 419033 [details] cvs diff Patch to FSM_RENAME case was applied on 15 Nov 2005 20:06:53 exactly as stated.
Comment 10 Michael Schröder 2010-06-02 14:22:33 UTC
Hmm, must have been a different branch. I just see the commit by Paul done Apr 16 13:26:12 2007, which doesn't contain it. rpm-18.104.22.168 also doesn't contain the FSM_RENAME part. Anyway, what's done is done. I don't want to do any finger pointing.
Comment 11 Jeff Johnson 2010-06-02 14:29:25 UTC
You chose to add the comment here with "you" attached. And not a different branch, 4.4.2 (on which @rpm.org is based) != 4.4.3.
Comment 12 Michael Schröder 2010-06-04 09:49:17 UTC
(Turns out that maybe I'm the one to blame. I seem to have dropped the chunk by accident when porting the patch from 4.1.1 to 4.4.2, and Paul took it from out version. Hard to tell after such a long time.)
Comment 13 Jeff Johnson 2010-06-04 12:54:07 UTC
Yes its been a long time and removing setuid/setgid (and capabilities and acls and ...) is a tedious issue which (if deserving of a CVE firedrill) also means that this rpmbuild issue also needs a CVE (imho its a far more serious issue): Name: tag with malicious syntax in spec files can be used to remove home directories: Name: foo;~ can trick rpmbuild into removing home directories and worse. Then there's %verifyscript that is run multiple times, and the flaw saving/restoring the chroot directory using embedded lua (also from you and incorrect). So it goes ... *shrug* ... Have fun!