Bug 601955 - (CVE-2010-2198) CVE-2010-2198 rpm: fails to drop POSIX file capabilities on package upgrade or removal
CVE-2010-2198 rpm: fails to drop POSIX file capabilities on package upgrade o...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
public=20100601,reported=20100601,sou...
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-08 18:43 EDT by Vincent Danen
Modified: 2015-07-31 07:56 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-20 07:09:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vincent Danen 2010-06-08 18:43:20 EDT
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.
Comment 1 Vincent Danen 2010-06-08 18:44:48 EDT
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.
Comment 2 Matt McCutchen 2010-06-11 04:17:02 EDT
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.
Comment 3 Fedora Update System 2010-06-11 08:35:24 EDT
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
Comment 4 Panu Matilainen 2010-06-14 06:42:12 EDT
(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.
Comment 5 Michal Schmidt 2010-06-16 07:03:48 EDT
(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.
Comment 6 Daniel Walsh 2010-06-16 11:24:44 EDT
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.
Comment 7 Vincent Danen 2010-06-17 18:14:30 EDT
Statement:

Not vulnerable.  RPM as provided with Red Hat Enterprise 3, 4, and 5 do not support POSIX capabilities.
Comment 8 Panu Matilainen 2010-06-30 06:30:54 EDT
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.
Comment 9 Fedora Update System 2010-06-30 06:43:44 EDT
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
Comment 10 Fedora Update System 2010-07-06 13:10:26 EDT
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.
Comment 11 Fedora Update System 2010-07-07 13:42:59 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.