Summary: | <app-backup/burp-2.1.32: privilege escalation via PID file manipulation | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Michael Orlitzky <mjo> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | marecki |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | B3 [glsa+ cve] | ||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 655950 | ||
Bug Blocks: |
Description
Michael Orlitzky
2017-08-23 20:31:56 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. 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). |