The tmpfiles.d entry for burp gives ownership of the PID file directory to the same user that the daemon runs as: $ cat /usr/lib/tmpfiles.d/burp.conf d /run/burp 0755 burp burp - As a result, the "burp" user can write whatever he wants into the PID file. Later, that may be exploitable: when the service is stopped, root will call "kill" on the contents of that file. But there's good news: even when running as the "burp" user, the daemon will create its PID file as root, before dropping privileges. For example on my system I see, $ sudo grep user /etc/burp/burp-server.conf # Run as different user/group. user=burp $ ls /run/burp total 4.0K -rw-r--r-- 1 root root 6 2017-08-23 16:23 burp.server.pid As a result, you can either leave /run/burp as root:root, or simply store the PID file in /run (as opposed to /run/burp) to avoid the vulnerability. In the systemd service file, I noticed you have, [Service] Type=simple PIDFile=/run/burp/burp.server.pid A "simple" service runs in the foreground, so I don't think you need the PIDFile line at all, even if the daemon creates one.
I wrote a long explanation here but my browser kindly axed it, therefore a short version this time. Chowning the pid-file directory was necessary in the event of burp server running as non-root for all version older than 2.1.18 because they dropped privileges before creading the pid file; this was only changed by upstream commit f765ad2c9f421eefcd3afc447ed45fa3fd2d17a0 in mid-August 2017. PIDFile was present in burp.service because it allowed systemd to get rid of leftover PID files after unit shutdown, that said I've checked that it does allow privilege escalation even for Type=simple services (in a slightly weird way - systemd ended up terminating both the correct process *and* the victim specified in the PIDFile) so now it is no longer set. As for the proper fix, it has been implemented in ebuilds for 2.1.24 for the dev branch and 2.0.54-r3 for the stable branch; in the latter case I have backported the aforementioned commit. Assuming neither of the two exhibits any major breakage within the next couple of days I will submit 2.0.54-r3 for fast-track stabilisation to supersede vulnerable 2.0.54, and remove the remaining vulnerable ebuilds (2.0.54, 2.0.54-r2, 2.1.22) from the tree.
Thank you for going the extra mile to fix this. I hate to say it, but while testing the fix I noticed another (unrelated) permissions issue that I'll open a separate bug for.
Sigh. s/2.0.54-r3/2.0.54-r4/, s/2.1.24/2.1.24-r1/.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5cd39164b55ee94a0754a89c0069f228e58183ee commit 5cd39164b55ee94a0754a89c0069f228e58183ee Author: Marek Szuba <marecki@gentoo.org> AuthorDate: 2018-05-29 09:25:37 +0000 Commit: Marek Szuba <marecki@gentoo.org> CommitDate: 2018-05-29 09:26:30 +0000 app-backup/burp: remove old following full stabilisation of 2.1.32 There are now no versions left in the tree that are vulnerable to either #628770 or #641842 Bug: https://bugs.gentoo.org/show_bug.cgi?id=628770 Bug: https://bugs.gentoo.org/show_bug.cgi?id=641842 Package-Manager: Portage-2.3.40, Repoman-2.3.9 app-backup/burp/Manifest | 1 - app-backup/burp/burp-2.0.54-r4.ebuild | 111 --------------------- app-backup/burp/burp-2.0.54.ebuild | 110 -------------------- .../burp-2.0.54-chuser_after_getting_lock.patch | 38 ------- .../files/burp-2.0.54-ncurses_pkg-config.patch | 37 ------- .../burp/files/burp-2.0.54-no_mkdir_run.patch | 10 -- .../files/burp-2.0.54-protocol1_by_default.patch | 24 ----- app-backup/burp/files/burp.tmpfiles | 1 - app-backup/burp/files/burp2.initd | 45 --------- 9 files changed, 377 deletions(-)
CVE-2017-18284 assigned to this issue.
This issue was resolved and addressed in GLSA 201806-03 at https://security.gentoo.org/glsa/201806-03 by GLSA coordinator Aaron Bauman (b-man).
