CVE-2017-7500 (Other, published 2018-08-13T17:29Z)
Description: value: 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.
Severity: HIGH (CVSS v3 base score: 7.8)
Weakness: CWE-59 \u2014 Improper Link Resolution Before File Access ('Link Following')
The product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.
Repository: https://github.com/rpm-software-management/rpm
Files changed:
lib/fsm.c
tests/data/SPECS/replacetest.spec
tests/rpmreplace.at
Commit message: Restrict following symlinks to directories by ownership (CVE-2017-7500)

Only follow directory symlinks owned by target directory owner or root.
This prevents privilege escalation from user-writable directories via
directory symlinks to privileged directories on package upgrade, while
still allowing admin to arrange disk usage with symlinks.

The rationale is that if you can create symlinks owned by user X you *are*
user X (or root), and if you also own directory Y you can do whatever with
it already, including change permissions. So when you create a symlink to
that directory, the link ownership acts as a simple stamp of authority that
you indeed want rpm to treat this symlink as it were the directory that
you own. Such a permission can only be given by you or root, which
is just the way we want it. Plus it's almost ridiculously simple as far
as rules go, compared to trying to calculate something from the
source vs destination directory permissions etc.

In the normal case, the user arranging diskspace with symlinks is indeed
root so nothing changes, the only real change here is to links created by
non-privileged users which should be few and far between in practise.
Unfortunately our test-suite runs as a regular user via fakechroot and
thus the testcase for this fails under the new rules. Adjust the testcase
to get the ownership straight and add a second case for the illegal
behavior, basically the same as the old one but with different expectations.


Vulnerable code:
static int fsmVerify(const char *path, rpmfi fi)
            if (S_ISDIR(dsb.st_mode)) return 0;
		rc = fsmVerify(fpath, fi);
%defattr(-,root,root,-)

Fixed code:
static int fsmVerify(const char *path, rpmfi fi, const struct stat *fsb)
	    uid_t luid = dsb.st_uid;
	    /* Only permit directory symlinks by target owner and root */
            if (S_ISDIR(dsb.st_mode) && (luid == 0 || luid == fsb->st_uid))
		    return 0;
		rc = fsmVerify(fpath, fi, &sb);
%{!?user: %global user root}
%defattr(-,%{user},%{user},-)
	--define "user $(id -u -n)" \
	--define "user $(id -u -n)" \
AT_SETUP([upgrade invalid locally symlinked directory])
AT_KEYWORDS([install])
AT_CHECK([
RPMDB_CLEAR
RPMDB_INIT
tf="${RPMTEST}"/opt/foo
rm -rf "${RPMTEST}"/opt/*
rm -rf "${TOPDIR}"

runroot rpmbuild --quiet -bb \
        --define "ver 1.0" \
	--define "filetype datadir" \
	--define "filedata README1" \
          /data/SPECS/replacetest.spec

runroot rpmbuild --quiet -bb \
        --define "ver 2.0" \
	--define "filetype datadir" \
	--define "filedata README2" \
          /data/SPECS/replacetest.spec

mkdir "${RPMTEST}"/opt/f00f
ln -s f00f "${RPMTEST}"/opt/foo
runroot rpm -U /build/RPMS/noarch/replacetest-1.0-1.noarch.rpm
test -L "${tf}" && test -d "${tf}" && runroot rpm -U /build/RPMS/noarch/replacetest-2.0-1.noarch.rpm
test -d "${tf}"
],
[0],
[],
[])
AT_CLEANUP