Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 628770 (CVE-2017-18284) - <app-backup/burp-2.1.32: privilege escalation via PID file manipulation
Summary: <app-backup/burp-2.1.32: privilege escalation via PID file manipulation
Status: RESOLVED FIXED
Alias: CVE-2017-18284
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
URL:
Whiteboard: B3 [glsa+ cve]
Keywords:
Depends on: 655950
Blocks:
  Show dependency tree
 
Reported: 2017-08-23 20:31 UTC by Michael Orlitzky
Modified: 2018-06-13 20:56 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Orlitzky gentoo-dev 2017-08-23 20:31:56 UTC
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.
Comment 1 Marek Szuba gentoo-dev 2017-12-20 16:51:05 UTC
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.
Comment 2 Michael Orlitzky gentoo-dev 2017-12-20 19:59:47 UTC
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.
Comment 3 Marek Szuba gentoo-dev 2017-12-21 14:44:49 UTC
Sigh. s/2.0.54-r3/2.0.54-r4/, s/2.1.24/2.1.24-r1/.
Comment 4 Larry the Git Cow gentoo-dev 2018-05-29 09:26:40 UTC
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(-)
Comment 5 Christopher Díaz Riveros (RETIRED) gentoo-dev Security 2018-06-04 03:12:44 UTC
CVE-2017-18284 assigned to this issue.
Comment 6 GLSAMaker/CVETool Bot gentoo-dev 2018-06-13 20:56:35 UTC
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).