[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 5 Mar 2011 23:48:07 +0300
From: Solar Designer <solar@...nwall.com>
To: Florian Zumbiehl <florz@...rz.de>
Cc: oss-security@...ts.openwall.com,
"Steven M. Christey" <coley@...us.mitre.org>,
Stefan Fritsch <sf@...itsch.de>, Jan Kaluza <jkaluza@...hat.com>,
Paul Martin <pm@...ian.org>, Petr Uzel <petr.uzel@...e.cz>,
Thomas Biege <thomas@...e.de>
Subject: Re: CVE Request -- logrotate -- nine issues
Hi Florian and all,
I'm sorry I ran out of time for this discussion yesterday.
Here's a thought that I did not convey yet:
If a log file directory is writable by the service pseudo-user, and you
make both the service and patched logrotate work with it safely, there's
still the problem of how the sysadmin can access those logs safely.
Normally, the admin would run a command like "less -n" on one of the log
files, as root. However, this may allow for DoS attacks via symlinks or
hard links to device files. Say, the compromised service may replace
its log file with a link to a tape device (rewinds tape on open) or to
/dev/port (locks up some machines on read).
The admin could "su" to the service pseudo-user, but that allows the
compromised service to attack the admin's terminal, accessing the fd via
/proc or ptrace of a process such as "less" running under the "su"
session. Only "su" itself is immune from such attacks (since it has its
"dumpable" flag cleared); its child processes are not. The attacker
would be able to print control characters directly to the terminal fd,
and to issue ioctl's on it, changing the terminal mode. This might have
a security impact worse than DoS. Sebastian - you could want to comment
on this (I recall your research).
A solution could be to use group read permissions, and to view logs as
neither root nor the service pseudo-user. This is good, but we can
hardly expect almost all sysadmins to do it in almost all cases,
although having the group pre-created and group read permissions
pre-configured in a distro would be of some help.
A more reliable solution (in terms of being safe from the attacks being
discussed here even when the sysadmins don't specifically try to access
log files safely) is simply to have services create log files before
they drop root (and indeed to have the directory only writable by root).
This is the case for all services that we currently have in Owl. By the
way, our syslogd runs as non-root, but it starts up as root and it
creates its log files in /var/log if necessary - before dropping to the
syslogd pseudo-user. In my opinion, that's how it should be done.
If a service starts up as non-root right away (such as via "su" in its
startup script), then there's also a problem with its pidfile. It has
to write the pidfile as non-root, and thus into a directory writable by
the service pseudo-user (well, or rewrite a file in-place, which has
its own issues). However, the pidfile is likely to be accessed by other
parts of the system - such as by startup scripts that use
/etc/init.d/functions and by programs invoked from there (such as
start-stop-daemon). Such accesses are likely to be made as root, and
the file contents are parsed by scripts/programs running as root. If
such parsing is not robust when faced with incorrectly formatted input,
we may have a local root vulnerability. And we almost certainly have
DoS potential via spoofed PIDs (have another service killed) and via
links to device files, like what I described above.
Our policy so far has been to ensure that all pidfiles are only writable
by root, and are in a directory only writable by root. This implies
that services are being started as root, create their pidfiles, and only
then switch to their proper pseudo-users.
On Fri, Mar 04, 2011 at 06:58:17PM +0100, Florian Zumbiehl wrote:
[...]
> it is planned to add a new config directive that allows to specify
> the credentials to be used for manipulating specific sets of log files,
> thus obviating the need for separate logrotate invocations but still
> letting the kernel take care of separating privileges.
This sounds good to me, but it does not solve other problems I pointed
out above. Would you also add a similar option to start-stop-daemon and
to the daemon() function in /etc/init.d/functions (or whatever a given
distro uses)? Maybe. But even if so, the problem with admin's read
access to the logs remains. Pre-create a log view group and pre-set
permissions to 640? Makes sense. Yet this is still not as good as
simply having the service start as root (and deal with log files and
pidfile as root), whenever possible at all, which I think it is possible
for system services provided in a distro.
As to services that a non-root user may want to run on their own, the
user would not be able to use the new user-switching feature of logrotate
anyway (no root access). So the user will run an instance of logrotate
under their account, which is already possible.
Don't get me wrong, I don't really object to logrotate being enhanced.
I just want to point out a few things (some of this is my opinion rather
than "the absolute truth"):
1. Other service packages need to be fixed anyway. Having logs and
pidfiles in service pseudo-user writable directories is problematic in
more ways. Those packages are the vulnerable/guilty ones.
2. Such an enhancement to logrotate is not as useful as it might appear
at first.
3. The current behavior of logrotate is not exactly a vulnerability in
logrotate. Lacking a potentially desirable security-relevant feature,
sure. Vulnerability in logrotate, no.
> Now, I guess the major motivation for such an approach over executing
> logrotate as the unprivileged user directly is backwards compatibility
> and how much of a nightmare the transition will be, somehow implicitly
> assuming that the similarity with the old mode of operation should
> provide for an easier change.
If you compare these two approaches - having logrotate switch
credentials vs. starting multiple instances of logrotate with proper
credentials right away - then I agree that the former approach might
be cleaner (same config file for all, etc.) However, neither solves
other issues (admin's access to log files, and system scripts/programs'
access to and parsing of pidfiles).
> However, this implicit assumption may actually be just that and nothing
> more. Namely, there are some ideas how logrotate could guess the
> credentials for some common setups when none have been specified in the
> config file so as to avoid having to security-patch dozens of packages,
> at least as a transitional mechanism. But it's rather unclear whether
> any of that will actually work to a sufficient degree to be useful (and
> the security of the heuristics to be used is what most of the remaining
> contention as to how to fix is about).
Oh, you do need to patch those dozens of packages for other reasons as
well. So a possible change to logrotate is just a hardening measure.
This may be fine if it's not used as an excuse not to fix those other
packages at all. But if we say that we're fixing vulnerabilities in
logrotate, we're sort of making such an excuse. It's better to say that
we're hardening logrotate to be safer when faced with broken service
packages, which are then to be fixed one by one.
Yet another issue/risk I did not mention/explain explicitly so far:
I've seen packages where the maintainer made the mistake of making the
log files directory writable by the service pseudo-user even though the
service did not depend on that in any way. That is, the service created
its log files before dropping root, as it should. This was the case for
the nginx package I mentioned in this thread. A possible logrotate
"fix" would not solve the problem to a significant degree: similar
attacks would remain possible against service startup (replace the log
file with a link, wait for service restart, enjoy the link target being
written to by the service). The fix, of course, is to change the log
files directory ownership in the package. Not to patch logrotate, which
is only a workaround for some of the attack vectors.
Package maintainers commonly make other mistakes of this nature as well,
making the service pseudo-user the owner of any/all of the following:
directory the service chroot's to, program binaries, config files, and
indeed pidfiles as mentioned above. Obviously, none of these are
fixable in logrotate. In my opinion, log file directories are just a
special case of this problem, and this special case does not move
responsibility from service packages to logrotate.
> If that doesn't work out and you have to patch dozens of packages in
> order to change their logrotate configs, you probably may just as well
> patch packages to switch to using their own logrotate instance. Or to a
> different strategy for logfile handling altogether.
Right. The latter.
> In particular so,
> given that quite a few of the affected packages in the case of debian
> (and I guess it's similar for other distros) do a chown -R on the log
> dir in their postinst scripts and thus will need a security patch for
> that anyhow.
Right. They should simply keep that directory owned by root and have
the service support that (if not already supported or even assumed,
which is often/usually the case).
> I guess I don't really have much of an opinion on that. The vulnerabilities
> should be fixed, and probably in a way that breaks existing setups as
> little as possible, I don't really care which side is declared defective
> and subsequently fixed in order to achieve that ;-)
I care because, in this case, I think that "which side is declared
defective" affects whether the vulnerabilities are fixed for real or
not. Thus, one side (service packages) needs vulnerability fixes and
the other (logrotate) may use some hardening (but that's tricky).
Maybe logrotate should simply refuse to run when the target directory is
writable by other than the user running logrotate (typically root), with
an option to accept the risk and force logrotate to run anyway. Sure,
this would break existing security-broken setups, but it would also
force package maintainers to fix their packages in this respect. ;-)
I am sorry for the length of this message, yet I hope it helps.
Thanks,
Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
