Created attachment 494700 [details] bitlbee.initd-r2 The init script for bitlbee gives ownership of its PID file directory to the "bitlbee" user: start () { ebegin "Starting bitlbee" checkpath -d -m 0755 -o bitlbee:bitlbee $(dirname ${PIDFILE}) This can be exploited by the bitlbee user to kill root processes, since when the service is stopped, root will send a SIGTERM to the contents of the PID file (which are controlled by "bitlbee"). I've rewritten the init script to work around this by having bitlbee drop privileges rather than having start-stop-daemon invoke the command after already having dropped them (pass -u to bitlbee, not start-stop-daemon). Bitlbee correctly creates the PID file as root, before dropping privileges, so that allowed me to move the pid file to /run/bitlbee.pid and avoid the vulnerability. I've also removed "need net", which requires a non-loopback interface to be up, from depend(). By default, any interface will do, since we bind to 0.0.0.0. And if you need a particular one, it has to be specified ("need net" will succeed if *any* of them come up). So, instead of "need net", I placed rc_need=net.lo in the conf.d file. This also prevents bitlbee from going down when you turn off the network. Finally, I changed the -F parameter to -D because it lets us get rid of the weird BITLBEE_STOP_ALL that didn't work for me when I tried it. I might not know what I'm doing here, so feel free to put that back if I screwed something up.
Created attachment 494702 [details] bitlbee.confd-r2
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=73ccf4a6bbacf812ff1d4da6e5e7f30de7d67aa4 commit 73ccf4a6bbacf812ff1d4da6e5e7f30de7d67aa4 Author: Tim Harder <radhermit@gentoo.org> AuthorDate: 2019-02-10 04:41:45 +0000 Commit: Tim Harder <radhermit@gentoo.org> CommitDate: 2019-02-10 04:46:03 +0000 net-im/bitlbee: version bump to 3.6 Also, simplify the init script. Bug: https://bugs.gentoo.org/631072 Closes: https://bugs.gentoo.org/640126 Signed-off-by: Tim Harder <radhermit@gentoo.org> net-im/bitlbee/Manifest | 1 + net-im/bitlbee/bitlbee-3.6.ebuild | 149 ++++++++++++++++++++++++++++++++++ net-im/bitlbee/bitlbee-9999.ebuild | 29 ++----- net-im/bitlbee/files/bitlbee.confd-r2 | 7 ++ net-im/bitlbee/files/bitlbee.initd-r2 | 7 ++ 5 files changed, 169 insertions(+), 24 deletions(-)
(In reply to Michael Orlitzky from comment #0) > Finally, I changed the -F parameter to -D because it lets us get rid of the > weird BITLBEE_STOP_ALL that didn't work for me when I tried it. This might cause issues with 'libpurple' plug-ins: Login error: Daemon mode detected. Do *not* try to use libpurple in daemon mode! Please use inetd or ForkDaemon mode instead. Or at least that's what I'm seeing now. Thanks!
(In reply to Chiitoo from comment #3) > (In reply to Michael Orlitzky from comment #0) > > Finally, I changed the -F parameter to -D because it lets us get rid of the > > weird BITLBEE_STOP_ALL that didn't work for me when I tried it. > > This might cause issues with 'libpurple' plug-ins: > > Login error: Daemon mode detected. Do *not* try to use libpurple in daemon > mode! Please use inetd or ForkDaemon mode instead. > > Or at least that's what I'm seeing now. > > Thanks! It's possible that simply switching it back to "-F" will fix the issue. The systemd service shipping with bitlbee-3.6 uses "-F" and sets "KillMode=process", which only kills the main process. So if *that* is correct, then maybe the default OpenRC behavior of killing only the process contained in the PID file will work too. I'm afraid this is too long ago for me to remember exactly why I changed it. I have to defer to the real users at this point.
Yeah... I noticed the date of this bug, and committer only after commenting... oops. Might have asked radhermit first (or opened a bug), had I noticed. Regardless, thanks again!
Maintainer(s): Please call for stabilization when ready. 3.6{,-r1} has been in-tree a while now.
(In reply to John Helmert III (ajak) from comment #6) > Maintainer(s): Please call for stabilization when ready. 3.6{,-r1} has been > in-tree a while now. Doing it.
x86 stable
amd64 stable
ppc stable
Thanks all. Please cleanup.
Resetting sanity check; package list is empty or all packages are done.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a6a693598258bfd203fda3274c388263ac8bb24c commit a6a693598258bfd203fda3274c388263ac8bb24c Author: Sam James <sam@gentoo.org> AuthorDate: 2020-09-09 15:55:01 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2020-09-09 15:55:01 +0000 net-im/bitlbee: security cleanup Bug: https://bugs.gentoo.org/631072 Package-Manager: Portage-3.0.4, Repoman-3.0.1 Signed-off-by: Sam James <sam@gentoo.org> net-im/bitlbee/Manifest | 1 - net-im/bitlbee/bitlbee-3.5.1.ebuild | 160 ----------------- .../bitlbee/files/bitlbee-3.5-verbose-build.patch | 200 --------------------- net-im/bitlbee/files/bitlbee.confd-r1 | 8 - net-im/bitlbee/files/bitlbee.initd-r1 | 30 ---- 5 files changed, 399 deletions(-)
Only DoS. So no GLSA. Closing.
