Common Vulnerabilities and Exposures assigned an identifier CVE-2010-2198 to the following vulnerability: Name: CVE-2010-2198 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2198 Assigned: 20100608 Reference: MLIST:[oss-security] 20100602 Re: CVE Request -- rpm -- Fails to remove the SUID/SGID bits on package upgrade (RH BZ#598775) Reference: URL: http://www.openwall.com/lists/oss-security/2010/06/02/3 Reference: MLIST:[oss-security] 20100603 Re: CVE Request -- rpm -- Fails to remove the SUID/SGID bits on package upgrade (RH BZ#598775) Reference: URL: http://marc.info/?l=oss-security&m=127559059928131&w=2 Reference: MLIST:[oss-security] 20100603 Re: CVE Request -- rpm -- Fails to remove the SUID/SGID bits on package upgrade (RH BZ#598775) Reference: URL: http://www.openwall.com/lists/oss-security/2010/06/03/5 Reference: MLIST:[oss-security] 20100604 Re: CVE Request -- rpm -- Fails to remove the SUID/SGID bits on package upgrade (RH BZ#598775) Reference: URL: http://www.openwall.com/lists/oss-security/2010/06/04/1 Reference: CONFIRM: http://rpm.org/gitweb?p=rpm.git;a=commit;h=4d172a194addc49851e558ea390d3045894e3230 Reference: CONFIRM: https://bugzilla.redhat.com/show_bug.cgi?id=598775 Reference: OSVDB:65144 Reference: URL: http://www.osvdb.org/65144 Reference: SECUNIA:40028 Reference: URL: http://secunia.com/advisories/40028 lib/fsm.c in RPM 4.8.0 and earlier does not properly reset the metadata of an executable file during replacement of the file in an RPM package upgrade or deletion of the file in an RPM package removal, which might allow local users to gain privileges or bypass intended access restrictions by creating a hard link to a vulnerable file that has (1) POSIX file capabilities or (2) SELinux context information, a related issue to CVE-2010-2059.
See bug #598775 for an initial description and comments of this issue. Because different CVE names were assigned for different, yet related, issues, a separate bug has been filed for this particular issue.
Does "SELinux context information" on an executable allow it to be run with privileges that are in any way elevated from what the user could otherwise achieve? Someone familiar with SELinux will have to answer this.
rpm-4.8.1-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/rpm-4.8.1-1.fc13
(In reply to comment #2) > Does "SELinux context information" on an executable allow it to be run with > privileges that are in any way elevated from what the user could otherwise > achieve? Someone familiar with SELinux will have to answer this. CC'ing dwalsh for comments/corrections but AFAIK: SELinux can be only used to further restrict permissions beyond what a user would otherwise be allowed to do. Hardlinked files "inherit" the security context of the target, so they are subject to the similar issues as capabilities and suid/sgid in a sense. Say you have an essentially unconfined binary in package foo, and you make a hardlink to that file to "stash it". If package foo is updated (to break the hardlink), and then a policy update brings a different policy and/or context for that binary, you /might/ now have a less restricted binary at your disposal. Or it might be a completely broken binary as the policy prevents the binary with old context from doing what it needs to do. Or something else. But this wont give you any extra permissions you wouldn't have on a non-selinux system. Also SELinux contexts cannot be "dropped", somewhat like you can't "drop" the uid and gid of a file; you can only change it to something else assuming you have sufficient privileges to do so. Unless SELinux has a built-in (ie doesn't depend on any particular policy being loaded) or otherwise run-time discoverable "deny everything" context which rpm could use to "drop" contexts to on upgrade/remove, there's not much rpm can do about it.
(In reply to comment #4) > Also SELinux contexts cannot be "dropped", somewhat like you can't "drop" the > uid and gid of a file; you can only change it to something else assuming you > have sufficient privileges to do so. Unless SELinux has a built-in (ie doesn't > depend on any particular policy being loaded) or otherwise run-time > discoverable "deny everything" context which rpm could use to "drop" contexts > to on upgrade/remove, there's not much rpm can do about it. "default_t" might be a good candidate. See http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-The_file_t_and_default_t_Types.html But it would be even better if there were a context which even unconfined_t could not access.
unconfined means unconfined. If you want to confine a user then use staff_u or some other confined user. SELinux context on a file might allow an application to transition do a different domain (process label) This label could have different access then the original process. Maybe more/Maybe less/ Maybe a combo of both. SELinux should not give any more access then if it was disabled. So it only further restricts on privs of DAC.
Statement: Not vulnerable. RPM as provided with Red Hat Enterprise 3, 4, and 5 do not support POSIX capabilities.
Removing the SELinux context part as it's doesn't give elevated privileges in the sense that SUID/SGID/capabilities do. Also SELinux context cannot be similarly dropped, only changed, and rpm has no way of knowing whether some other context would be "more secure" than the one a given file to be unlinked/replaced currently has.
rpm-4.7.2-2.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/rpm-4.7.2-2.fc12
rpm-4.7.2-2.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
rpm-4.8.1-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.