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.
$ ls /run/burp
-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,
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):
Author: Marek Szuba <firstname.lastname@example.org>
AuthorDate: 2018-05-29 09:25:37 +0000
Commit: Marek Szuba <email@example.com>
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
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).