Bug 1450369 (CVE-2017-7500) - CVE-2017-7500 rpm: Following symlinks to directories when installing packages allows privilege escalation
Summary: CVE-2017-7500 rpm: Following symlinks to directories when installing packages...
Status: CLOSED WONTFIX
Alias: CVE-2017-7500
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: impact=moderate,public=20170703,repor...
Keywords: Security
Depends On: 1467374
Blocks: 1450373
TreeView+ depends on / blocked
 
Reported: 2017-05-12 10:56 UTC by Adam Mariš
Modified: 2019-06-08 22:00 UTC (History)
9 users (show)

(edit)
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.
Clone Of:
(edit)
Last Closed: 2017-11-02 13:51:31 UTC


Attachments (Terms of Use)
Fix issue with directories changing meta data (1.75 KB, patch)
2017-05-16 12:42 UTC, Florian Festi
no flags Details | Diff
Open newly created files with O_EXCL to make sure there is not a symlink already (2.47 KB, application/mbox)
2017-05-23 15:22 UTC, Florian Festi
no flags Details
Add check when reopening hard linked files (1.41 KB, application/mbox)
2017-05-23 15:24 UTC, Florian Festi
no flags Details
Open existing files with w+ to avoid messing up files if things go wrong. (827 bytes, application/mbox)
2017-05-23 15:25 UTC, Florian Festi
no flags Details

Description Adam Mariš 2017-05-12 10:56:33 UTC
It was found that rpm follows symlinks to directories when installling packages which can be leveraged by local attackers to escalate their privileges when next package upgrade happens.

Upstream fix:
https://github.com/rpm-software-management/rpm/commit/f2d3be2a8741234faaa96f5fd05fdfdc75779a79 
https://github.com/rpm-software-management/rpm/commit/c815822c8bdb138066ff58c624ae83e3a12ebfa9

Comment 1 Adam Mariš 2017-05-12 10:56:37 UTC
Acknowledgments:

Name: Ludwig Nussel (SUSE)

Comment 3 Florian Festi 2017-05-16 12:42 UTC
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.

Comment 4 Florian Festi 2017-05-23 15:22 UTC
Created attachment 1281637 [details]
Open newly created files with O_EXCL to make sure there is not a symlink already

Comment 5 Florian Festi 2017-05-23 15:24 UTC
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.

Comment 6 Florian Festi 2017-05-23 15:25 UTC
Created attachment 1281639 [details]
Open existing files with w+ to avoid messing up files if things go wrong.

Comment 7 Cedric Buissart 🐶 2017-05-24 13:26:04 UTC
To clarify : the issue affects rpmlib, thus other tools using rpmlib to install RPMs, such as yum and dnf, are affected too.

Comment 9 Cedric Buissart 🐶 2017-07-03 14:56:08 UTC
Created rpm tracking bugs for this issue:

Affects: fedora-all [bug 1467374]

Comment 10 Cedric Buissart 🐶 2017-07-03 15:42:05 UTC
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 11 Cedric Buissart 🐶 2017-07-03 15:42:18 UTC
Comment on attachment 1281639 [details]
Open existing files with w+ to avoid messing up files if things go wrong.

Moved to BZ 1452133

Comment 12 Cedric Buissart 🐶 2017-07-04 06:56:57 UTC
Comment on attachment 1281638 [details]
Add check when reopening hard linked files

Moved to BZ 1452133

Comment 13 Panu Matilainen 2017-10-26 09:19:27 UTC
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

Comment 14 Cedric Buissart 🐶 2017-10-26 16:14:38 UTC
Thanks!
Obsoleting the attached patch to prevent confusion & adding the links to the bug description.

Comment 15 Cedric Buissart 🐶 2017-11-02 13:51:41 UTC
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/.


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