Bug 601956 (CVE-2010-2199)
Summary: | CVE-2010-2199 rpm: fails to drop POSIX ACLs on package upgrade or removal | ||
---|---|---|---|
Product: | [Other] Security Response | Reporter: | Vincent Danen <vdanen> |
Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | unspecified | CC: | ffesti, jnovy, matt, n3npq, pmatilai |
Target Milestone: | --- | Keywords: | Security |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-06-23 08:38:42 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Vincent Danen
2010-06-08 22:46:54 UTC
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? 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. 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 ... I agree with comment #2. Who submitted the CVE? It should be retracted, and this bug closed as NOTABUG. (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. 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. 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). 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. 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. (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. 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. (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 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. (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. (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. 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. 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 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. 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. 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. (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. 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. 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. (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). Thank you! 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. |