[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D74CDB1.2060503@redhat.com>
Date: Mon, 07 Mar 2011 13:21:05 +0100
From: Jan Kaluža <jkaluza@...hat.com>
To: Solar Designer <solar@...nwall.com>
CC: oss-security@...ts.openwall.com,
"Steven M. Christey" <coley@...us.mitre.org>,
Stefan Fritsch <sf@...itsch.de>, 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
Hi all,
sorry for not replying earlier, but I hadn't Internet access during weekend.
On 03/05/2011 10:35 PM, Solar Designer wrote:
> On Fri, Mar 04, 2011 at 07:51:02PM +0100, Jan Lieskovsky wrote:
>> I got your point. But still think there is a difference between the
>> case privileged system user would use 'cp' by accident in untrusted
>> directory and corrupt the system and case, when some utility is
>> running under privileged user account on regular basis and not
>> taking 'untrusted directories' into account / not having a policy,
>> how to behave while processing them.
>
> Definitely. I fully agree that there's a vulnerability in the system if
> it has a non-root writable log directory yet runs logrotate on that
> directory as root. The question is what part of the system the
> vulnerability lies in. I say that it's in the directory permissions,
> which usually come from the service package. We could harden logrotate
> to deal with such misconfigurations in a safer way (once we figure out
> how), but not blame it.
I fully agree. As it has been already said in this thread, we have
thought about some ways how to "fix" it only on logrotate's side, but it
has been proved it's practically impossible and after reading this
thread I think (and agree with you) it's really more global problem.
I also think the fix in affected packages is needed to fix this problem
(We have tried to get around this, but I don't believe it's possible).
What I would suggest as logrotate improvement is to create new config
directive (Florian already described this strategy in this thread) which
could be used by admin to set proper user/group for particular rotation.
This doesn't fix the global problem, but improves handling of it by
logrotate. I already have patch, but I'll wait for end of this discussion.
I think logrotate should skip rotation of files in unsafe directories
and show error message instead. Logrotate should also contain something
like "--force" switch (this name is already used, so we have to find
better one, but I don't have anything better in mind just now). With
this switch logrotate should *not* skip unsafe directories and rotate
them as it currently does, but show the error message. Basically it
allows backward compatibility.
>> For example CVE-2010-2055 has been assigned to Ghostscript's reading
>> of initialization files from $CWD. CVE-2010-3349, 3350, 3355, 3369 and
>> many others have been assigned to insecure library loading vulnerabilities.
>>
>> In comparison with the above, how running of logrotate utlity on untrusted
>> directory differs? Even when it is often run regularly and under root
>> user account.
>
> Reading files from cwd, unless very explicitly documented, may
> reasonably be an unexpected risk for a knowledgeable user. In contrast,
> logrotate is being explicitly told to access a certain directory. It's
> more similar to cp'ing a file, where you give the filename explicitly.
> So neither cp nor logrotate are to blame.
>
>> How many system users check the directory permissions prior running
>> the utility? How many administrators check them regularly?
>
> If properly configured initially, log directory permissions are not to
> change on their own. Otherwise, your argument could be extended onto
> any other part of the system - "how many administrators check the
> permissions on /, on /bin/sh, and on /etc/passwd regularly?" This
> becomes a system integrity checking question, which applies or does
> not apply regardless of logrotate.
Agree.
>> Agree, the majority of these issue would disappear when logrotate
>> would just refuse to process such a directory. But currently it
>> doesn't. That CVE request is just attempt to pinpoint the need
>> of change.
>
> OK, the need of change. Would that change be, as you say, to have
> logrotate refuse to process an unsafe directory? If so, I support this
> (although calling the lack of this hardening measure a vulnerability in
> logrotate is a stretch). However, I am concerned that another change
> may go in (fine by itself) and it would be used as an excuse not to fix
> the service packages (not fine). I am commenting in this thread mostly
> to avoid responsibility being taken off those flawed service packages.
> I really don't mind having logrotate hardened in one way or another as
> long as the service packages are to be fixed as well.
That's what my first reaction in this mail is about. We haven't found
any solution which would fix current situation properly just by patching
logrotate without breaking backward compatibility (and if you break
backward compatibility, then packages has to be fixed anyway).
>>> 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.
>>
>> Agree here. But as stated above, how many sysadmins perform this task
>> prior running the tool? How many do it regularly?
> [...]
>> See above. Ghostscript vs logrotate. How untrusted directory for GS
>> differs from untrusted directory for logrotate?
>
> I think I've addressed these same questions above, so I am not repeating
> the answers here.
>
>>> No software is perfect, and almost any piece of software can be improved
>>> endlessly. But that's mere rhetoric.
>>
>> Sure. Just wanted to differentiate the 'unsupported functionality'
>> from undocumented functionality, which may be harmful.
>
> Understood and agreed. But in this case we're dealing with
> "undocumented functionality" that is expected by anyone familiar
> with Unix. Much like it is expected that "cp" in an untrusted directory
> may happen to follow a link. This is different from some program
> checking cwd for its config file, which could not be inferred from
> general Unix experience.
>
>>> 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.
>>
>> See above -- absence of policy how to deal with untrusted directories.
>
> Yes, but that's the case for almost all other Unix programs, with very
> few exceptions. So a person familiar with Unix should assume that if no
> policy is stated, the program is unsafe to use on untrusted directories.
>
>> How many users check content of their $CWD prior launching gs?
>
> I agree with you that undocumented reading from cwd is a vulnerability.
> (Also, even if users checked their cwd, there would be a race.)
>
> This is just different from the issue at hand. I've tried to explain
> (in several paragraphs above) why/how I see it different.
>
>> Same from my side. Thanks for the thoughts, which initiated (partial)
>> discussion.
>
> A "full" discussion of the issues involved can be very time-consuming,
> as evidenced by the length of these messages... So I think we'll have
> to wrap up soon. ;-)
>
> Thanks,
>
> Alexander
Regards,
Jan Kaluza
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.
