It seems that thin server stores server PIDs somewhere and signals them without actually verifying that the PID is still valid and belongs to the thin server. In other words, if thin server dies before the kill, it can kill random processes reusing the same PID. Stopping server on 127.0.0.1:11009 ... Sending QUIT signal to process 21488 ... process not found! Sending KILL signal to process 21488 ... /var/www/packages.gentoo.org/htdocs/vendor/bundle/ruby/2.2.0/gems/thin-1.6.4/lib/thin/daemonizing.rb:143:in `kill': No such process (Errno::ESRCH) from /var/www/packages.gentoo.org/htdocs/vendor/bundle/ruby/2.2.0/gems/thin-1.6.4/lib/thin/daemonizing.rb:143:in `force_kill' from /var/www/packages.gentoo.org/htdocs/vendor/bundle/ruby/2.2.0/gems/thin-1.6.4/lib/thin/daemonizing.rb:138:in `rescue in send_signal' from /var/www/packages.gentoo.org/htdocs/vendor/bundle/ruby/2.2.0/gems/thin-1.6.4/lib/thin/daemonizing.rb:122:in `send_signal' from /var/www/packages.gentoo.org/htdocs/vendor/bundle/ruby/2.2.0/gems/thin-1.6.4/lib/thin/daemonizing.rb:111:in `kill' from /var/www/packages.gentoo.org/htdocs/vendor/bundle/ruby/2.2.0/gems/thin-1.6.4/lib/thin/controllers/controller.rb:94:in `block in stop' from /var/www/packages.gentoo.org/htdocs/vendor/bundle/ruby/2.2.0/gems/thin-1.6.4/lib/thin/controllers/controller.rb:135:in `tail_log' from /var/www/packages.gentoo.org/htdocs/vendor/bundle/ruby/2.2.0/gems/thin-1.6.4/lib/thin/controllers/controller.rb:93:in `stop' from /var/www/packages.gentoo.org/htdocs/vendor/bundle/ruby/2.2.0/gems/thin-1.6.4/lib/thin/runner.rb:200:in `run_command' from /var/www/packages.gentoo.org/htdocs/vendor/bundle/ruby/2.2.0/gems/thin-1.6.4/lib/thin/runner.rb:156:in `run!' from /usr/lib64/ruby/gems/2.2.0/gems/thin-1.7.2/bin/thin:6:in `<top (required)>' from /usr/bin/thin:9:in `load' from /usr/bin/thin:9:in `<main>'
The thin init script gives ownership of its PID file directory to its runtime user: THIN_USER=${THIN_USER:-root} THIN_GROUP=${THIN_GROUP:-root} THIN_PID=${THIN_PID:-/var/run/thin/thin.pid} [...] start_pre() { # If the path to the pidfile is /var/run/thin/foo/thin.pid # then checkpath will fail if /var/run/thin/ does not exist. # This caught infra... d=$(dirname ${THIN_PID}) mkdir -p "$d" checkpath -d -m 0775 -o ${THIN_USER}:${THIN_GROUP} "$d" } That can be exploited by $THIN_USER to kill root processes, since when the service is stopped, root sends a SIGTERM to the contents of the PID file (which are controlled by $THIN_USER). If it is really necessary that the PIDFILE location is owned by $THIN_USER than it looks like the privilege drop happens before the PID file gets written, so the PID file winds up being owned by the runtime user (and thus we require the parent directory to be writable by it). You may be able to work around the issue by having OpenRC background the process and manage its PID file when you run thin in non-daemon mode. With the daemon running in the foreground, you can set command_background=true in the init script, and OpenRC will take care of the PID file for you. At which point it becomes appropriate to set pidfile="/run/${RC_SVCNAME}.pid" and to drop the start_pre() function. Since /run is owned by root, that will avoid the vulnerability.
From db2de955d5f996cecf3495d50fa264683a43e13f Mon Sep 17 00:00:00 2001 From: Hans de Graaff <graaff@gentoo.org> Date: Wed, 20 Nov 2019 18:53:40 +0100 Subject: www-servers/thin: remove last-rited package Signed-off-by: Hans de Graaff <graaff@gentoo.org> --- www-servers/thin/Manifest | 1 - www-servers/thin/files/thin.confd-2 | 39 ---------------- www-servers/thin/files/thin.initd-r4 | 87 ----------------------------------- www-servers/thin/metadata.xml | 16 ------- www-servers/thin/thin-1.7.2.ebuild | 88 ------------------------------------ 5 files changed, 231 deletions(-) delete mode 100644 www-servers/thin/Manifest delete mode 100644 www-servers/thin/files/thin.confd-2 delete mode 100644 www-servers/thin/files/thin.initd-r4 delete mode 100644 www-servers/thin/metadata.xml delete mode 100644 www-servers/thin/thin-1.7.2.ebuild
This issue was resolved and addressed in GLSA 202007-40 at https://security.gentoo.org/glsa/202007-40 by GLSA coordinator Sam James (sam_c).
