Bug 598775 (CVE-2010-2059) - CVE-2010-2059 rpm: fails to drop SUID/SGID bits on package upgrade
Summary: CVE-2010-2059 rpm: fails to drop SUID/SGID bits on package upgrade
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2010-2059
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 598832 598934 626707 626708 626709 626710
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-06-02 02:37 UTC by Matt McCutchen
Modified: 2019-09-29 12:36 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 598832 (view as bug list)
Environment:
Last Closed: 2012-02-14 13:57:11 UTC
Embargoed:


Attachments (Terms of Use)
SRPM for testing this bug (2.14 KB, application/x-rpm)
2010-06-02 02:37 UTC, Matt McCutchen
no flags Details
SRPM reproducer, compatible also with older RHELs/Fedoras (1.94 KB, application/x-rpm)
2010-06-02 09:10 UTC, Jindrich Novy
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2010:0678 0 normal SHIPPED_LIVE Moderate: rpm security update 2010-09-07 14:35:00 UTC
Red Hat Product Errata RHSA-2010:0679 0 normal SHIPPED_LIVE Moderate: rpm security and bug fix update 2010-09-07 14:32:33 UTC

Description Matt McCutchen 2010-06-02 02:37:02 UTC
Created attachment 418879 [details]
SRPM for testing this bug

Description of problem:
When RPM replaces an executable, it does not clear the setuid and setgid bits of the old file.  Thus, if a user made a hard link to the old executable, he/she will still be able to run it with elevated privileges.  This is bad if it was replaced because it had a vulnerability.  The problem seems to occur only when executables are replaced, not when they are erased.

This is the same bug that was previously noted in dpkg:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=225692

Version-Release number of selected component (if applicable):
rpm-4.8.0-14.fc13.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Rebuild the attached SRPM twice, once with -D 'rel 1' and once with -D 'rel 2'.
2. mkdir /tmp/rpm-setuid-test
3. rpm -i rpm-setuid-test-0-1.fc13.$(rpm -E '%{_build_arch}').rpm
4. ln /usr/bin/rpm-setuid-test /tmp/rpm-setuid-test/
5. rpm -U rpm-setuid-test-0-2.fc13.$(rpm -E '%{_build_arch}').rpm
6. ls -l /tmp/rpm-setuid-test/rpm-setuid-test

Actual results:
The old executable is setuid.

Expected results:
The old executable is not setuid.

Comment 1 Panu Matilainen 2010-06-02 05:04:52 UTC
Ah, good catch. Rpm does actually remove the SUID/SGID bits when removing packages, but not on upgrade. Will fix...

Comment 2 Panu Matilainen 2010-06-02 06:31:54 UTC
Fixed upstream + building for rawhide now, updates to released versions to follow (AFAIK this affects every single released rpm version out there...)

Comment 3 Jan Lieskovsky 2010-06-02 08:44:04 UTC
Upstream patch for the SUID/SGID bits removal part:
  [1] http://rpm.org/gitweb?p=rpm.git;a=commit;h=ca2d6b2b484f1501eafdde02e1688409340d2383

Upstream patch for the POSIX file capabilities removal part:
  [2] http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=4d172a194addc49851e558ea390d3045894e3230

Comment 5 Jindrich Novy 2010-06-02 09:10:04 UTC
Created attachment 418968 [details]
SRPM reproducer, compatible also with older RHELs/Fedoras

This src.rpm is the same as the original one but recreated with md5 digests and gz payload so that it is installable even on older RHELs/Fedoras.

Comment 10 Jan Lieskovsky 2010-06-02 11:23:31 UTC
Information about vulnerable package versions:

  1, SUID/SGID bits removal part:
    This issue affects the versions of the rpm package,
    as shipped with Red Hat Enterprise Linux 3, 4, and 5.

    This issue affects the versions of the rpm package,
    as shipped with Fedora releases of 11, 12, and 13.

  2, POSIX file capabilities removal part:
    This issue DO not affect the versions of the rpm package,
    as shipped with Red Hat Enterprise Linux 3, 4, and 5
    (POSIX file capabilities were introduced starting
     from v2.6.24 version of the Linux kernel).

    This issue affects (in sense of vulnerable code part
    presence) the versions of the rpm package, as shipped
    with Fedora releases of 11, 12, and 13. Though the
    file capability support is NOT used in these rpm
    versions yet.

Comment 11 Jan Lieskovsky 2010-06-02 11:45:04 UTC
CVE Request:
  [1] http://www.openwall.com/lists/oss-security/2010/06/02/2

Comment 12 Michael Schröder 2010-06-02 13:03:40 UTC
Sigh, my original patch from 2005 (bug #125517) already had that change for the FSM_RENAME case, but the chunk somehow was lost when the patch was integrated...

Comment 13 Jan Lieskovsky 2010-06-04 08:34:45 UTC
This is CVE-2010-2059.

Comment 14 Panu Matilainen 2010-06-04 08:45:32 UTC
(In reply to comment #12)
> Sigh, my original patch from 2005 (bug #125517) already had that change for the
> FSM_RENAME case, but the chunk somehow was lost when the patch was
> integrated...    

I get access denied for bug 125517 for whatever reason... But regardless of
where, how and when the chunk got lost, AFAICT there's no FSM_RENAME chunk in
rpm-4.4.2 based OpenSUSE (sbitcheck.diff, which is probably the one that got
applied to current rpm.org tree) and SLED versions (in rpm-4.4.2.diff). So
you'll at least want to double-check the situation in your distros too.

Comment 15 Jan Lieskovsky 2010-06-04 09:19:50 UTC
(In reply to comment #14)
> (In reply to comment #12)
> I get access denied for bug 125517 for whatever reason... But regardless of

Added you to that bug.

> where, how and when the chunk got lost, AFAICT there's no FSM_RENAME chunk in
> rpm-4.4.2 based OpenSUSE (sbitcheck.diff, which is probably the one that got
> applied to current rpm.org tree) and SLED versions (in rpm-4.4.2.diff). So
> you'll at least want to double-check the situation in your distros too.

Comment 16 Panu Matilainen 2010-06-04 09:28:47 UTC
(In reply to comment #10)
> Information about vulnerable package versions:
>
>   2, POSIX file capabilities removal part:
>     This issue DO not affect the versions of the rpm package,
>     as shipped with Red Hat Enterprise Linux 3, 4, and 5
>     (POSIX file capabilities were introduced starting
>      from v2.6.24 version of the Linux kernel).
> 
>     This issue affects (in sense of vulnerable code part
>     presence) the versions of the rpm package, as shipped
>     with Fedora releases of 11, 12, and 13. Though the
>     file capability support is NOT used in these rpm
>     versions yet.    

A slight correction/clarification: rpm in Fedora >= 11 comes with file capability packaging support enabled, but to my knowledge this feature is not /used/ by any packages in any distribution (Fedora or otherwise) yet. 

Another twist is that the file capability support is a compile-time optional feature, and rpm will only be able to drop capabilities from hardlinks IFF capability support is enabled in rpm itself by --with-cap option to configure.
Thus it's recommended that rpm is always built with --with-cap option on distributions with filesystem level support for POSIX file capabilities to enable rpm to drop capabilities potentially set by administrators/package scriptlets.

Comment 17 Michael Schröder 2010-06-04 09:42:12 UTC
#14: Yes, all suse versions with have rpm >= 4.4.2.3 are vulnerable, too. The ones with 4.1.1 are not vulnerable, as they use the original patch.

I wonder why it's not in rpm-4.4.2.diff, I can't remember how I generated the diff. Maybe I didn't apply the hunk and Paul took the patch from our rpm-4.4.2 diff, so maybe I'm to blame for this mess.

Comment 18 Panu Matilainen 2010-06-04 11:06:01 UTC
(In reply to comment #17)
> #14: Yes, all suse versions with have rpm >= 4.4.2.3 are vulnerable, too. The
> ones with 4.1.1 are not vulnerable, as they use the original patch.

AFAICT not just rpm >= 4.4.2.3 but rpm >= 4.4.2.

> I wonder why it's not in rpm-4.4.2.diff, I can't remember how I generated the
> diff. Maybe I didn't apply the hunk and Paul took the patch from our rpm-4.4.2
> diff, so maybe I'm to blame for this mess.    

No fingerpointing intended. You reported the issue with a complete patch in bugzilla, at that point a wrong patch ending up in the rpm.org tree (years after the fact) is hardly your fault either.

Comment 21 Vincent Danen 2010-06-08 22:49:06 UTC
See bug #601955 for CVE-2010-2198 (rpm: fails to drop POSIX file capabilities/SELinux context information on package upgrade or removal)

See bug #601956 for CVE-2010-2199 (rpm: fails to drop POSIX ACLs on package upgrade or removal)

Comment 22 Panu Matilainen 2010-06-09 09:10:25 UTC
Err, this is getting rather mixed up.

The issues at hand are
1) RPM fails to drop SUID/SGID bits on package upgrade (and removal for rpm < 4.4.2.1)
2) RPM fails to drop POSIX file capabilities on package upgrade and removal, which is simply the more fine-grained analogue of case 1). This only affects systems with filesystem-level support for POSIX file capabilities.

IMO there's little point having separate CVE's for the cases but if we must ... at least lets get the descriptions straight. POSIX ACL's and SELinux contexts aren't involved as they dont have additional means to gain extra privileges through execution AFAICT.

Comment 23 Fedora Update System 2010-06-11 11:41:59 UTC
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 24 Fedora Update System 2010-06-11 12:35:17 UTC
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 25 Matt McCutchen 2010-06-11 20:11:26 UTC
I realized that hard links are not the only way to retain access to an old executable.  The attacker can simply open it and later exec it via /proc/self/fd.  On some filesystems (in my testing, ext2 but not reiserfs), the attacker can even resurrect the file using linkat(2) with AT_SYMLINK_FOLLOW.  So, Panu, your commit 89be57ad9239c9ada0cba94a5003876b456d46bf is wrong; please revert it.

Comment 26 Vincent Danen 2010-06-12 01:28:56 UTC
MITRE also assigned CVE-2005-4889 to this issue:

lib/fsm.c in RPM before 4.4.3 does not properly reset the metadata of
an executable file during deletion of the file in an RPM package
removal, which might allow local users to gain privileges by creating
a hard link to a vulnerable (1) setuid or (2) setgid file, a related
issue to CVE-2010-2059.

This is because CVE-2010-2059 specifically refers to RPM package upgrades, whereas CVE-2005-4889 specifically refers to RPM package removals (because SUSE had addressed the removal aspect previously, but not the upgrade aspect).

Comment 27 Matt McCutchen 2010-06-12 02:27:45 UTC
The failure to clear set[ug]id bits on package removal (CVE-2005-4889) was addressed a long time ago in bug 125517.  It is not within the scope of this bug.

Comment 28 Panu Matilainen 2010-06-14 07:53:15 UTC
(In reply to comment #25)
> I realized that hard links are not the only way to retain access to an old
> executable.  The attacker can simply open it and later exec it via
> /proc/self/fd.  On some filesystems (in my testing, ext2 but not reiserfs), the
> attacker can even resurrect the file using linkat(2) with AT_SYMLINK_FOLLOW. 
> So, Panu, your commit 89be57ad9239c9ada0cba94a5003876b456d46bf is wrong; please
> revert it.    

Mm... open() requires read (or write, duh) permission on the file, which no program with SUID/SGID bits enabled should have. Sure the link count test could be removed, it's there only to avoid unnecessary work in the common case. This just raises the question: how far should rpm go babysitting packagers/admins? Disallow creating packages with SUID/SGID on readable/writable files? If an admin changes permissions of an executable to something "vulnerable", is it rpm's job to try and mop it under the carpet?

Comment 29 Matt McCutchen 2010-06-14 12:45:53 UTC
(In reply to comment #28)
> (In reply to comment #25)
> > I realized that hard links are not the only way to retain access to an old
> > executable.  The attacker can simply open it and later exec it via
> > /proc/self/fd.  On some filesystems (in my testing, ext2 but not reiserfs), the
> > attacker can even resurrect the file using linkat(2) with AT_SYMLINK_FOLLOW. 
> > So, Panu, your commit 89be57ad9239c9ada0cba94a5003876b456d46bf is wrong; please
> > revert it.    
> 
> Mm... open() requires read (or write, duh) permission on the file, which no
> program with SUID/SGID bits enabled should have.

Where is that documented?  Feel free to file bugs on all the packages that don't comply:

$ find / -xdev -type f -perm /004 -perm +6000 -ls 2>/dev/null
-rwsr-xr-x   1 root     root        32472 Feb 13 20:40 /bin/su
-rwsr-xr-x   1 root     root        37864 Mar  5 03:58 /bin/ping
-rwsr-xr-x   1 root     root        74680 May 19 07:50 /bin/mount
-rwsr-xr-x   1 root     root        32504 Mar  5 03:58 /bin/ping6
-rwsr-xr-x   1 root     root        49280 May 19 07:50 /bin/umount
-rwsr-xr-x   1 root     root        28744 Jun  8 01:13 /bin/fusermount
-rwsr-xr-x   1 root     root        57728 Mar 19 02:56 /usr/bin/at
-r-xr-sr-x   1 root     tty         11104 Apr 26 06:00 /usr/bin/wall
-rwsr-sr-x   1 root     root        49416 Feb 19 03:42 /usr/bin/crontab
-rwsr-xr-x   1 root     root        59440 Apr 28 09:34 /usr/bin/chage
-rwxr-sr-x   1 root     tty         12024 May 19 07:50 /usr/bin/write
[...]

> Sure the link count test could
> be removed, it's there only to avoid unnecessary work in the common case.

Clearing the set[ug]id bits is conditioned on the executable being set[ug]id in the first place, which is not the common case, so the unnecessary work there should be minimal.  This concern applies more to file capabilities.

Comment 30 Fedora Update System 2010-06-30 10:43:37 UTC
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 31 Fedora Update System 2010-07-06 17:10:16 UTC
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 32 Fedora Update System 2010-07-07 17:42:52 UTC
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.

Comment 33 Matt McCutchen 2010-08-14 07:21:02 UTC
As per bug 598934 comment #4, this is fixed in Fedora.

Comment 37 Matt McCutchen 2010-08-24 19:01:56 UTC
Tomas, why did you change the "whiteboard" field to values that do not match https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-2059 ?

Comment 38 Tomas Hoger 2010-08-25 08:23:02 UTC
Whiteboard contains our score, it's not just a copy-n-paste of NVD one.  In this case, NVD score does not follow 3.1.1 #1 scoring guide guideline.

Comment 39 errata-xmlrpc 2010-09-07 14:32:38 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2010:0679 https://rhn.redhat.com/errata/RHSA-2010-0679.html

Comment 40 errata-xmlrpc 2010-09-07 14:35:23 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 4

Via RHSA-2010:0678 https://rhn.redhat.com/errata/RHSA-2010-0678.html


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