New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tinyproxy should create its PID file before dropping privileges (CVE-2017-11747) #106
Comments
|
well, here-in lies a debate: Tiny proxy should never run as root even temporarily unless it's binding to a low port, period. My initscript is perfectly valid to be of the form: 'su user tinyproxy -c blah'. there are many, many programs that own and write arbitrary values to their pid files. I don't think we need to make tiny insulate itelf from stupid sysadmins. There are no wide-spread reports that I know of people trashing their systems by carelessly signalling the arbitrary value.
|
|
@tb3088 and how does your init script stop tinyproxy? |
|
I would also like to know what distributions have |
|
the LSB init scripts have for years not required a pid file. They use things like pidof or pgrep. |
|
755 and 777 are not "same difference," one is perfectly secure and is what everyone uses -- the other gives root privileges to everyone. In particular, no one uses mode 777 on
|
|
I meant Amazon Linux runs 755 as well. It doesn't really matter if /var/run is root only or not. Say your pid file gets written to /var/run/tinyproxy/myport.pid. You have the exact same problem. The issue isn't who writes the pid file. The issue is don't blindly trust contents. That said, something like this is ingrained in pretty much any sysadmin. I think the only real solution is TinyProxy, nay all programs simply do not write their pid files, ever. It's the caller's responsibility to do it. If said caller can't write to the system pid directory, too bad. |
|
|
|
If you can't trust the contents of the PID file, why have it at all? It's useless, like I mentioned over in issue #24. The problem with that is that PID files are the standard way to stop, reload, flush -- whatever -- a running daemon. There is no way to stop a running instance of tinyproxy without knowing its PID. If you can't get that PID from the PID file -- where can your init script get it from? |
|
since your init system starts the process, shouldn't it take care of the bookkeeping ? |
|
@rofl0r you seem to be suggesting that a PID file isn't necessary at all. Disregarding the fact that all daemons have used a PID file for 40 years and the practical problems of determining the PID after a fork -- right now, tinyproxy is writing a vulnerable PID file. If the maintainers decide to fix the vulnerability by eliminating the PID file entirely (and making tinyproxy impossible to use with e.g. sysvinit), then so be it. But so long as it writes the PID file, it should do so securely. |
|
indeed. i'm pondering the possibility of just removing the usage of the pid file altogether, together with the logfile, which imo should just be printed to stdout (and no daemonizing being done either), since at least in the init implemenation i'm using, |
|
SystemD and OpenRC can do something similar, but you can't count on every init system or platform supporting it. For example, the first sentence of the tinyproxy webpage is "Tinyproxy is a light-weight HTTP/HTTPS proxy daemon for POSIX operating systems," and systemd is explicitly not POSIX (it only works on relatively new Linux systems). If your daemon doesn't background itself and doesn't write a PID file, then the init system needs to,
Maybe it's a noble goal but the scope is a lot bigger than what I'm prepared to take on. For now I just want to eliminate the risk to people using the PID file. |
say what? There's pidof, pgrep, and other LSB programs to bear. It's foolish to rely on the contents of a pidfile and just because root wrote it doen't mean it's safe. Less so these days but some programs liked to put multiple lines in their pidfiles (eg. the command-line args when it was invoked) which obviously screw with the kill command if just consumed naively. Systemd is the proud recipient of a Pwnie and should not be considered an init system at all, but rather a built-in hacker's delight to all stupid enough to run it. (seriously, read the list of insane bugs that project is known for - but enough OT). re;
Tiny simply needs to focus on not doing something stupid (like running as Root forever or failing to give up privs for lack of error handling) and writing PID files is not important and again OS dependent. The correct answer is, don't do it and let the OS packager do his proper duty. |
|
I haven't checked, but suspect Tiny doesn't check to see if the log file is a link. Personally I prefer the behavior of If Exist and not a file (optional; or not owned by my EUID), remove, recreate; or bail on logging to that file. Writing to syslog() is of course an expected feature. |
|
@tb3088 If you really think it can be done, just write me an init script that doesn't trust the contents of the PID file. I don't think you'll be able to, and attempting to do it will reveal the inherent difficulties better than arguing with me will. |
|
Any comment from upstream? Since this is a minor issue, I don't want to sit on the CVE announcement forever. I'll probably announce it within the week if no one asks me not to. |
|
@orlitzky explicitly, please let me read up on this and come back to you soon. |
|
@obnoxxx gotcha, no problem |
|
Ping =) |
Resolves tinyproxy#106 Signed-off-by: Michael Adam <obnox@samba.org>
|
The Patch of PR #120 has been merged. |
|
I'm not convinced. create_file_safely() doesn't look safe at all. Or heck, what if I name my pidFile something dangerous? So SSHD blindly follows symlinks and truncates the destination file. Oops! I copied /etc/passwd to a separate file, symlinked to it from /var/run and hilarity ensued. |
Fair point, but that's a different issue, right? Let's see:
That sounds fair.
Ok. So the file exists and is a symlink, bail out.
Well that's misconfiguration then. We can never fully protect from that, right?
Sorry you lost me, what's sshd got to do with it? Any more things? |
|
an earlier version of my comment mentioned SSHd and Apache as examples to perhaps mimic. Until I looked at SSHd which does bad things. |
|
@obnoxxx thanks!
Well, it indicates that something is wrong. Maybe you tried to start two separate tinyproxy instances and forgot to give the second one a different pid file name. Either overwriting the existing file or throwing an error (telling the admin to check and possibly clean up the existing file) sound reasonable to me.
The theme of this vulnerability is that the pid file (and thus its parent directory) must not be writable by anyone other than root. If root creates a symlink to
If you want to hose your own system as root, no one's going to stop you. But only root can name the pid file. |
|
my point is checking for pid files is the wrapping script's responsibility. If exist, check for running program, if not delete it, then invoke TP binary. But as far as teh binary is concerned, if a file exists, log the error, don't do anything and definitely don't follow anything. Predicating the program's "safe operation" on the pid_dir being root only is idiotic. Dont' write a pid file at all and this whole mess goes away. Not to mention TP should never be run as root in the first place. It should ~never be configured to listen to a low port. If you need it to, then use xinetd or iptables to redirect packets. The program is mightily untrustworthy as it is. Introducing more vulnerability is not the right thing to do. |
It's your lucky day: You are welcome to start tinyproxy as an unprivileged user and forego the PID file if you have some other means of stopping it. But for the people using init scripts with PID files, things are now a tiny bit safer. |
|
excellent. So now we're down to you only need root to bind to a low port. Since .../run/tinyproxy/ should be owned by the post-dropprivs() account. and even if you have nasties in that directory it can't do bad things. |
Resolves #106 Signed-off-by: Michael Adam <obnox@samba.org>
Summary
The tinyproxy daemon should create its PID file before dropping
privileges. This represents a minor security issue; additional factors
are needed to make it exploitable.
Description
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 fulfill 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. If one daemon
flushes its cache in response to SIGUSR2 and another daemon drops all
connections in response to SIGUSR2, it is not hard to imagine a
denial-of-service by the user of the first daemon against the second.
Exploitation
There is only a risk of exploitation when some other user relies on
the data in the PID file. But you have to wonder, what's the point of
the PID file if not to provide the PID to other people? Any situation
where the PID file is used is therefore suspicious.
The text was updated successfully, but these errors were encountered: