[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 4 Mar 2011 20:05:03 +0300
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: "Steven M. Christey" <coley@...us.mitre.org>,
Stefan Fritsch <sf@...itsch.de>, Jan Kaluza <jkaluza@...hat.com>,
Florian Zumbiehl <florz@...rz.de>, Paul Martin <pm@...ian.org>,
Petr Uzel <petr.uzel@...e.cz>, Thomas Biege <thomas@...e.de>
Subject: Re: CVE Request -- logrotate -- nine issues
On Fri, Mar 04, 2011 at 04:35:03PM +0100, Jan Lieskovsky wrote:
> For issue #5:
>
> If the mail configuration directive is used, an attacker can trick
> logrotate into sending arbitrary files by mail, by creating
> appropriate hard or soft links.
>
> Hope that's enough, let me know if not.
I can definitely figure this out by looking at the code, but the
description alone looks insufficient to me. It does not say what
directory those links would need to be created in. If it's the log
files' directory, which I suspect is the case, then this issue falls in
the same controversial category as most of the rest. If it's /tmp, then
this is in fact a vulnerability in logrotate, without a doubt.
> >The rest, as described, appear to rely on sysadmin error and to assume
> >security properties that logrotate never advertised it had. Specifically,
> >logrotate was never declared to be safe to use on untrusted directories,
> >and it was an error for a sysadmin to make such an assumption.
>
> We don't mind documenting of this behavior in appropriate places.
Do you mean the fact that logrotate is not meant for use on untrusted
directories? Or, on the contrary, claim that it is safe for that after
the hardening changes to be made now? I prefer the former.
> Wouldn't like to condescend further into particulars, what is and what
> is not a security issue (as this is beyond this post), but according
> to our opinion even non-documented incorrect behavior, allowing
> malicious actions to be performed on the system, should be considered
> a security flaw (regardless if it's advertised or not). Because by applying
> your above approach, most of the open source project could just say
> 'this software is not intended to be run like that.'
Like I wrote in my reply to Florian, this is about expectations. You
say "incorrect behavior", which makes sense to me. For example, "cp"
is also unsafe in untrusted directories, but its behavior is
nevertheless "correct" (because it is documented), so you would not call
it a security flaw for that reason. Fair enough.
However, then there are things such as text editors, which are also
unsafe for use on files in untrusted directories. Is it "incorrect
behavior" that they are? To me, this has always been the historically
expected unsafety. However, Dan Rosenberg managed to get a CVE id for
such an issue in an editor. I was surprised. The issue did not affect
us (we were not packaging the editor), but if it did we would not call
it a vulnerability. Just wrong/flawed expectations by the user.
Again, as I wrote to Florian, maybe the expectations here are changing
over the years. However, if so, wouldn't it be right to have hardening
introduced into the relevant programs first, the expectations
"officially" changed (although I'd rather not do that), and only if/when
that hardening is later determined to be insufficient start saying
"vulnerability" and assigning CVE ids?
Speaking of issues where a more or differently privileged process
accesses files in a directory writable by another process, these are
surprisingly difficult to "fully" deal with, and the majority of
programs are "affected". Of the common Unix commands, only a handful
are safe to use in untrusted directories (with possible impact of
attacks being a mere DoS against the command itself) - such as "ln".
Yes, I actually use "ln" like this:
# su - user1
$ cp some/dir/file . # hopefully the ~/file name was not taken
$ exit
# ln ~user1/file .
# ls -ld file # sanity check that we were not raced
# chown user2: file
# ln file ~user2/
# rm file
# su - user2
$ mv file target/dir/
$ exit
# su - user1
$ rm file
when I need to copy a file from one untrusted user to another. Yes,
this is complicated and it has limitations (same fs). Maybe we need a
special tool for this task (I had some ideas on this - "give" and "take"
commands). But that's the current situation.
Almost all other commands and programs are unsafe on untrusted
directories. In my opinion, that's the only correct assumption for a
sysadmin to make, and any other assumption is naive. Unfortunately,
most sysadmins don't fully realize this (in my experience), but that
does not make those programs any safer, nor does it prompt us to assign
CVE ids against almost all Unix programs.
> Not trying to argue,
I also primarily mean to share some info/understanding/reasoning rather
than to argue.
> just saying the disclination like the above doesn't help anyone.
I think it does. But I am willing to shut up. ;-) I sure am not going
to post stuff that people don't want to receive/read. ;-)
> Either the software has the issues, and they should be fixed,
> or it has the issues, and they can't be fixed. Then the software
> should not be used and an alternative one should be found.
No software is perfect, and almost any piece of software can be improved
endlessly. But that's mere rhetoric.
I don't mind logrotate being hardened against these issues. We do a lot
of hardening in other areas, so why not here. I just don't blame
logrotate for the issues. I blame improper service packages and
insufficient sysadmin education. Hardening logrotate and not fixing
those other truly broken packages sounds plain wrong to me. The latter
part of it (not fixing), not the former. As to CVE ids against
logrotate, I don't care much; it's just that we're not going to say our
logrotate update fixes 9 vulnerabilities. We may say it fixes one (the
#8 issue).
> This is not you would shoot yourself into the foot by accident
> (by performing some action). This is about local users', aware
> of the deficiencies, ability to conduct such actions on the system,
> so they would reach some higher privilege, damage or different
> kind of benefit for them.
Sorry, your desired meaning of the above escapes me... Nevermind.
Thank you for your response!
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.
