app-arch/rpm2targz: multiple vulnerabilites (CVE-2010-{2059,2197,2198,2199})

[Jeff Johnson]

tracker

[Vincent (vincent-redhat-bugs)]

Common Vulnerabilities and Exposures assigned an identifier CVE-2010-2199 to
the following vulnerability:

Name: CVE-2010-2199
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2199
Assigned: 20100608
Reference: CONFIRM: https://bugzilla.redhat.com/show_bug.cgi?id=125517

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 bypass intended access restrictions
by creating a hard link to a vulnerable file that has a POSIX ACL, 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.

[Tomas (tomas-redhat-bugs)]

Do we know of any case where this is an issue? Or how is this different from not doing chmod 0700 or even chmod 0 on package upgrade / removal?

Do we use posix ACLs in any of Fedora or RHEL rpms?

[Panu (panu-redhat-bugs)]

Well I wonder where the heck did this POSIX ACL-part come from. It was not part of what was originally reported, rpm doesn't even support setting ACL's from packages and AFAICT, SUID/SGID isn't settable in ACL's so users cannot gain extra privileges on execution through them.

[Jeff (jeff-redhat-bugs)]

Hint:

Removing privilege (particularly when not from *.rpm packaging) will
never find the holy grail ...

Verify whether st->st_nlink is as "expected" on erase and whine if not.

Fully fuliginous credit from plagarists is de rigueur ...

[Matt (matt-redhat-bugs)]

I agree with comment #2. Who submitted the CVE? It should be retracted, and this bug closed as NOTABUG.

[Matt (matt-redhat-bugs)]

(In reply to comment #2)
> Well I wonder where the heck did this POSIX ACL-part come from.

On second thought, the one and only reference cited by CVE-2010-2199 is bug 125517, so I bet the idea came from bug 125517 comment 13. It's still wrong.

[Jeff (jeff-redhat-bugs)]

Wrong? Perhaps you should add some karma to these bug reports ... ah
bugzilla doesn't have negative karma ...

The mechanism for the escalation vector for all of
    setuid/setgid has CVE (and ancient fix resurrected)
    capabilities has CVS (and current fix)
    ACL's "wrong"
    XATTR's SE Linux uses these
is identical:

   Robert uses RPM to install a file on a path attaching metadata to inode.
   Malicious Mark (or Sysadmin Susie) creates a hardlink to the file.
   Robert removes the package and RPM removes the file it created.

Either _ALL_ or _NONE_ of the metadata cleanup issues that are left attached to Mark's
hardlink that (possibly) can be used as escalation vectors need to be addressed by RPM.
Nothing else makes logical sense.

Which was one point in comment #13 in #125517. Another point is that there
are far more severe problems in RPM including that syntax errors like
    Name: foo;~
in spec files can be used to trick rpmbuild into removing home directories and worse.

Who decides what issues get CVE's and which do not? Damfino.

[Vincent (vincent-redhat-bugs)]

MITRE assigned these CVEs. We can certainly dispute the CVE assignment if we feel it is in error.

If rpm doesn't set POSIX ACLs then we probably should dispute it (regardless of the other capabilities because each of those has their own CVE name). It can't be a vulnerability if rpm never sets them (and I don't think we can call it a vulnerability in rpm if an admin sets a POSIX ACL, the file gets hardlinked, and rpm doesn't remove the ACLs that a) it never set and b) doesn't know about).

[Jeff (jeff-redhat-bugs)]

OK, so no CVS for POSIX ACL's because "rpm never sets them".

SO let's move to SE Linux XATTR's attached to Malicious Mark's
hardlinked inode after RPM has done unlink(2).

RPM most definitely sets SE Linux xattr's on files.

Show me the CVE for XATTR's or the reasoning why SE Linux XATTR's should
not _ALSO_ be not disputed as unworthy of a CVE.

Please note that capabilities and setuid/setgid proceed immediately
after hearing your response to SE Linux XATTR's.

And you _REALLY_ need to look carefully at doing a CVE for
    Name: foo;~
vulnerabilities instead of hardlink side effects.

[Jeff (jeff-redhat-bugs)]

Apologies, I suffer from keyboard typing lag on Mac OS X Snow Leopard.

This typing of mine
    Show me the CVE for XATTR's or the reasoning why SE Linux XATTR's should
    not _ALSO_ be not disputed as unworthy of a CVE.
should have been
    Show me the CVE for XATTR's or the reasoning why SE Linux XATTR's should
    _ALSO_ not be disputed as unworthy of a CVE.
Not the permutation of "not" and "be" and the removal of a double negative
that makes me look like an idiot.

The reasoning re "attributes" that potentially lead to escalation that
remain after RPM does unlink(2) with the information that RPM "knows"
is sound even if I can't type worth a damn.

NONE of this crap is worthy of *ANY* CVE. The creation of a hardlink
outside of RPM package management is no problem that could/should/would
be meaningfully resolved in RPM itself.

Arguably RPM should verify st->st_nlink to be as "expected"
before doing unlink(2) and spew a warning if not. Any other
implementation is deranged. JMHO, YMMV, everyone's (and clearly MITRE's)
does.

[Matt (matt-redhat-bugs)]

(In reply to comment #6)
> The mechanism for the escalation vector for all of
> setuid/setgid has CVE (and ancient fix resurrected)
> capabilities has CVS (and current fix)
> ACL's "wrong"
> XATTR's SE Linux uses these
> is identical:
>
> Robert uses RPM to install a file on a path attaching metadata to inode.
> Malicious Mark (or Sysadmin Susie) creates a hardlink to the file.
> Robert removes the package and RPM removes the file it created.

At this point, Mark has a hard link to a file that was previously RPM-managed. You haven't described the actual escalation.

> Either _ALL_ or _NONE_ of the metadata cleanup issues that are left attached to
> Mark's
> hardlink that (possibly) can be used as escalation vectors need to be addressed
> by RPM.

POSIX ACLs do not constitute an escalation vector that would allow a user to run the executable with privileges he/she could not otherwise obtain.

[Jeff (jeff-redhat-bugs)]

Creating a hardlink (in most cases for RPM managed files) assumes privilege
that makes any other escalation vector through hardlinks to "previously RPM-manged"
files moot.

And if hardlink creation is possible, its a packaging, not an RPM implementation,
error.

But feel fee to file all the CVE's you want against RPM for _NOT_ cleaning up
metadata data (be it setuid/capability/ACL/XATTR) attached to an inode
that was "previously RPM-managed" if/when a hardlink has been created
through external means.

You might well report the same problems against rm(1) since the same
system call unlink(2) is unaware of unknown persistent side effects if/when
an additional hardlink has been created.

There are -- in fact -- no escalations of note reported for any of the (2? or is it 3 now?)
CVE's being reported against RPM.

[Matt (matt-redhat-bugs)]

(In reply to comment #11)
> Creating a hardlink (in most cases for RPM managed files) assumes privilege
> that makes any other escalation vector through hardlinks to "previously
> RPM-manged"
> files moot.

How? Please be specific.

I agree that it would be highly desirable to block the hard-linking, but that is a moot point because the attack does not actually require hard links, as I noted in bug 589775 comment #25.

> You might well report the same problems against rm(1) since the same
> system call unlink(2) is unaware of unknown persistent side effects if/when
> an additional hardlink has been created.

In principle, you are right. However, I think it's reasonable to start with RPM because it is by far the most frequent unlinker of privileged executables on Fedora. (As an anecdote, when I realized a custom program I was writing for my system would require a setuid wrapper, my gut feeling told me I should install it with RPM rather than manually in /usr/local, even though I was unaware of this issue at the time.) Addition of a --clear-caps option to the relevant coreutils can be considered in a separate bug.

> There are -- in fact -- no escalations of note reported for any of the (2? or
> is it 3 now?)
> CVE's being reported against RPM.

Maybe not against RPM, but the Debian bug I cited in bug 589775 comment #0 linked to a report of the attack being performed against dpkg:

http://www.hackinglinuxexposed.com/articles/20031111.html

[Jeff (jeff-redhat-bugs)]

So start with rpm. Nothing whatsoever stops you from inventing
escalation scenarios and filing as many CVE's as one wishes.

No I don't care to be specific. If you don't understand that
externally created hardlink's are external to package management,
and should be dealt with

If you _REALLY_ want to stop escalation, then wipe the
blocks of erased files before calling unlink(2). Destroying
the content preventing any possibility of an exploit no matter
what privileges are attached to the inode. Even simpler would
be calling ftruncate, though I dare say you will find certain
libraries that are unhappy having ftruncate(2) called
while in use won't be happy.

Attacks against dpkg and anecdotal evidence regarding
your gutsy instestinal fluids are utterly irrelevant.

[Matt (matt-redhat-bugs)]

(In reply to comment #13)
> No I don't care to be specific.

Then your claim in comment #11 will remain unsubstantiated.

> If you don't understand that
> externally created hardlink's are external to package management,
> and should be dealt with

As I said, this argument is moot because the attack can be performed without creating a hard link (bug 589775 comment #25).

> If you _REALLY_ want to stop escalation, then wipe the
> blocks of erased files before calling unlink(2). Destroying
> the content preventing any possibility of an exploit no matter
> what privileges are attached to the inode. Even simpler would
> be calling ftruncate, though I dare say you will find certain
> libraries that are unhappy having ftruncate(2) called
> while in use won't be happy.

That actually may be a good future-proof solution.

> Attacks against dpkg [...] are utterly irrelevant.

Attacks that also apply to RPM are utterly relevant.

[Matt (matt-redhat-bugs)]

(In reply to comment #7)
> MITRE assigned these CVEs. We can certainly dispute the CVE assignment if we
> feel it is in error.

Please do, and close this bug as NOTABUG. POSIX ACLs do not permit privilege escalation, so there is no need to clear them, period.

> If rpm doesn't set POSIX ACLs then we probably should dispute it (regardless of
> the other capabilities because each of those has their own CVE name). It can't
> be a vulnerability if rpm never sets them (and I don't think we can call it a
> vulnerability in rpm if an admin sets a POSIX ACL, the file gets hardlinked,
> and rpm doesn't remove the ACLs that a) it never set and b) doesn't know
> about).

With respect to attributes that do permit privilege escalation, the opposite stance is taken in bug 598775 comment #16, second paragraph.

[Jeff (jeff-redhat-bugs)]

Doing chattr +i prevents hardlink creation. That is intrinsically a better
approach than having applications like rpm(8) and rm(1) and ... attempt
to detect and remove hardlinks.

As you have seen with linkat and /proc/self/fd testing st->st_nlink is not
enough.

[Jeff (jeff-redhat-bugs)]

Creating a partition that contains _ONLY_ setuid/setgid binaries
not only makes finding _ALL_ setuid/stegid programs trivial,
but also prevents hardlinks without the necessity of chatter.

Either chattr all setuid/setgid programs, or isolate on a separate
partiotion preventing xdev hardlinks are intrinsically sounder
approaches then pasting CVE's against RPM

[Jeff (jeff-redhat-bugs)]

The /boot partition (with another directory for _ONLY_ setuid/setgid/capability
privileged programs) is one obvious solution that is transparent to existing
sysadmin and distro pragma's: Add symlinks into the /boot/suid (or
whatever) partition that isolates privileged programs from being hardlinked.

And then mount / with nosuid if you _REALLY_ want to prevent any other
buggy & privileged programs from being hardlinked.

Q.E.D. Total time to solution: 20 minutes.

But honk away at RPM CVE's if you must.

[Matt (matt-redhat-bugs)]

Jeff, this bug is about POSIX ACLs. If you'd like to substantiate your claim that they pose a risk, you are welcome to do so here. The other discussion does not belong on this bug.

[Jeff (jeff-redhat-bugs)]

I made no claim that POSIX ACL's have any security risk.

What I said is

1) there is other data attached to an inode beyond setuid/setgid/capabilities
that also will track with hardlink attacks. And its not just privilege escalation
that can lead to attack vectors, all of ACL's/capabilities/setuid needs to be considered.

2) the solution should not be attempted in RPM, nor with endless
CVE's. RPM (or any application) cannot solve hardlink attacks.

3) There are other and more serious issues in RPM that are in
need of a CVE.

I'm not the moron who decided that a CVE was needed because RPM
did not clear POSIX ACL's

And I'm also not the moron who claimed that I dropped a security related
patch while checking into RPM CVS back in 2005.

[Matt (matt-redhat-bugs)]

(In reply to comment #20)
> I made no claim that POSIX ACL's have any security risk.

Good, then there is no disagreement about closing this bug.

If there are other attacks, please file separate bugs rather than making vague comments here.

[Jeff (jeff-redhat-bugs)]

Are you referring to the
     Name: foo;~
issue in RPM?

There is already a bug report, and several issues with the
patch identified explicitly.

And there is no CVE (or security fix release) afaik for an issue that
was 1st reported to a vendor-sec representative in January 2009,
and was later refound and refixed @rpm.org (but without realeasing
fixes last I checked.

So I will stick with "vague", thank you. Its a wasted effort to file bug reports.

[Jeff (jeff-redhat-bugs)]

Another vague comment:

RPM itself has extraordinary privilege from existing SELInux policy.

The privilege is dropped if/when rpm does execv(2) by calling rpm_execcon in libselinux.

There are several paths to abuse of the security tags attached to /bin/rpm
that do not call rpm_execcon(2) (using internal lua and or macro evaluation)
if /bin/rpm is hardlinked from somwhere else instead.

Whether there is an exploit by hardlink'ing /bin/rpm is left as an exercise.

Its not just setuid/capabilities attached to an inode that need to be removed.

[Vincent (vincent-redhat-bugs)]

(In reply to comment #22)
> Are you referring to the
> Name: foo;~
> issue in RPM?
>
> There is already a bug report, and several issues with the
> patch identified explicitly.

This issue has a CVE name (CVE-2010-2197; bug #603244). Any further discussion about it should probably happen there rather than in bug #125517 where it was originally noted (due to it being an unrelated issue to what the bug report was originally for).

[Jeff (jeff-redhat-bugs)]

Thank you!

[Vincent (vincent-redhat-bugs)]

Statement:

We do not consider RPM's lack of removing POSIX ACLs to be security sensitive. Users cannot use POSIX ACLs to elevate their privileges; therefore, there is no need to clear them upon package upgrade or removal.

[Jeff Johnson (n3npq)]

The patch to fix this issue was added to rpm-4.4.3 and remains in @rpm5.org code since 2005.

The @rpm.org code base was based on rpm-4.4.2 and part of the patch (from OpenSuSE)
was dropped when backported.

Upgrading to rpm-4.8.1 will fix CVS-2010-2191.

[Jeff Johnson (n3npq)]

Upgrading to rpm-4.8.1 will fix CVS-2010-2199.