Bug 1450369 (CVE-2017-7500)
| Summary: | CVE-2017-7500 rpm: Following symlinks to directories when installing packages allows privilege escalation | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Adam Mariš <amaris> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | cbuissar, ffesti, ignatenko, kardos.lubos, mjw, packaging-team-maint, pmatilai, security-response-team, vmukhame |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | rpm 4.13.0.2, rpm 4.14.0 | Doc Type: | If docs needed, set a value |
| Doc Text: |
It was found that rpm did not properly handle RPM installations when a destination path was a symbolic link to a directory, possibly changing ownership and permissions of an arbitrary directory, and RPM files being placed in an arbitrary destination. An attacker, with write access to a directory in which a subdirectory will be installed, could redirect that directory to an arbitrary location and gain root privilege.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-11-02 13:51:31 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: | |||
| Bug Depends On: | 1467374 | ||
| Bug Blocks: | 1450373 | ||
| Attachments: | |||
|
Description
Adam Mariš
2017-05-12 10:56:33 UTC
Acknowledgments: Name: Ludwig Nussel (SUSE) Created attachment 1279319 [details]
Fix issue with directories changing meta data
This only addresses half of the issue. RPM clearly should not touch /etc here but instead apply the meta data to the symlink itself.
This does not deal with the issue that rpm installs files at locations directed by altered/newly created symlinks.
Created attachment 1281637 [details]
Open newly created files with O_EXCL to make sure there is not a symlink already
Created attachment 1281638 [details]
Add check when reopening hard linked files
If the directory of a hard linked files is writable to a non priviledged user the user could try to replace the hard link with a symolic link during the istallation process and have rpm overwrite an arbitrary file. This check issues an error in this case.
Created attachment 1281639 [details]
Open existing files with w+ to avoid messing up files if things go wrong.
To clarify : the issue affects rpmlib, thus other tools using rpmlib to install RPMs, such as yum and dnf, are affected too. Created rpm tracking bugs for this issue: Affects: fedora-all [bug 1467374] Comment on attachment 1281637 [details] Open newly created files with O_EXCL to make sure there is not a symlink already Moved to BZ 1452133 Comment on attachment 1281639 [details] Open existing files with w+ to avoid messing up files if things go wrong. Moved to BZ 1452133 Comment on attachment 1281638 [details] Add check when reopening hard linked files Moved to BZ 1452133 Fixed upstream some time ago and now included in two releases: rpm 4.13.0.2 and 4.14.0. The upstream fix is quite different from the patch in comment #3, because rpm really must follow legitimate symlinks to directories, the question is determining what is a legitimate link (and what isn't). The upstreamed rule is that rpm only follows directory symlinks owned by the target directory owner or root, longer rationale + the patches are here: https://github.com/rpm-software-management/rpm/commit/f2d3be2a8741234faaa96f5fd05fdfdc75779a79 https://github.com/rpm-software-management/rpm/commit/c815822c8bdb138066ff58c624ae83e3a12ebfa9 Thanks! Obsoleting the attached patch to prevent confusion & adding the links to the bug description. Statement: Red Hat Product Security has rated this issue as having Moderate security impact. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/. |