| Keywords: Mode: All keywords (AND) |
|
Mon Aug 28, 2017 18:14
|
mjo: Actually, smsd is able to remove the pidfile even when it's owned by root and is not writable for smsd. That is because the directory /var/run/smstools is owned by smsd:smsd. This directory must be writable because the infofile is also created into this directory, and during that the smsd is running as a restricted user.
Once the PID file is created by root, you would store it directly in /var/run (which is owned by root) and not /var/run/smstools.
My script certainly is not POSIX compliant, I guess, but the requirements are also slightly different than usual.
The reason I'm harping on POSIX compliance is because, when I announce this, I'd like to be able to tell people how to fix it. Anyone who can use your init script might be OK, but for example, I discovered the issue on Gentoo. They have an official smstools package, and their init scripts might be run on Linux, FreeBSD, or even OSX. If your stop() function won't run on one of those systems, then I can't just say "copy and paste the upstream stop() function" to the Gentoo maintainer.
|
|
Wed Aug 23, 2017 23:25
|
mjo: I've tried to write a pure-POSIX init script that does this correctly, and it's a lot harder than it sounds. With `pidof`, the problem is that it can return more than one PID. With most init systems, it's possible to run multiple instances of a daemon with e.g. different config files. You wouldn't want to kill them both when you stop one, and there's no way to tell them apart. It's unlikely, but you also risk killing the processes of anyone who is running smsd interactively (say, to test a patch out of his home directory).
You could check that the PID contained in the PID file matches one of the PIDs returned by `pidof`, but even then, that could kill a second smsd running under a different user. And `pidof` is part of a third-party package that isn't guaranteed to be installed =)
I wouldn't swear that it can't be done, but it's not straightforward. And everyone who ships an init script would have to implement the same tricks.
The reason I suggested creating the PID file before dropping privileges is that, relatively at least, it's easy to write the PID file cleanup code. All I have to do in my init script is check if the process I tried to kill is gone, and rm the PID file if it is. That takes a line or two and is hard to get wrong -- many init systems (I have experience only with OpenRC) can even take care of it for you.
|
|
Mon Aug 21, 2017 11:46
|
mjo: Hi, I've found a minor security issue in smsd.
Summary
The smsd daemon should create its PID file before dropping
privileges. This represents a minor security issue; additional factors
are needed to make it exploitable.
Details
The purpose of the PID file is to hold the PID of the running daemon,
so that later it can be stopped, restarted, or otherwise signalled
(many daemons reload their configurations in response to a SIGHUP).
To fulfil that purpose, the contents of the PID file need to be
trustworthy. If the PID file is writable by a non-root user, then he
can replace its contents with the PID of a root process. Afterwards,
any attempt to signal the PID contained in the PID file will instead
signal a root process chosen by the non-root user (a vulnerability).
This is commonly exploitable by init scripts that are run as root and
which blindly trust the contents of their PID files. The SMS Server
Tools themselves ship such an init script, scripts/sms3, which
contains e.g. the following:
PID=`cat $PIDFILE 2>/dev/null`
if [ "x$PID" != x ]; then
P=`kill -0 $PID 2>/dev/null`
In the above snippet, the contents of the $PID variable are controlled
by the smsd daemon user, while "kill" is run as root.
Exploitation
An example of a problematic scenario involving an init script would be,
1. I run "/etc/init.d/smsd start" to start the daemon.
2. smsd drops to the "smsd" user.
3. smsd writes its PID file, now owned by the "smsd" user.
4. Someone compromises the daemon.
5. The attacker is generally limited in what he can do because the
daemon doesn't run as root. However, he can write "1" into the
PID file, and he does.
6. I run "/etc/init.d/smsd stop" to stop the daemon while I investigate
the weird behavior resulting from the hack.
7. The machine reboots, because I killed PID 1 (this is normally restricted
to root).
Resolution
The problem is avoided by creating the PID file as root, before dropping
privileges.
Note however that currently, smsd tries to clean up its PID file if the
daemon terminates abnormally:
void abnormal_termination(int all)
{
...
remove_pid(pidfile);
That will no longer be possible if the PID file is owned by root and the
daemon is running as a restricted user. Instead, the init system should
check to see if killing the daemon worked, and if it did, remove the PID
file.
|
