Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 7 Mar 2011 15:30:58 -0500 (EST)
From: Josh Bressers <bressers@...hat.com>
To: oss-security@...ts.openwall.com
Cc: Solar Designer <solar@...nwall.com>,
        "Steven M. Christey" <coley@...us.mitre.org>,
        Stefan Fritsch <sf@...itsch.de>, Florian Zumbiehl <florz@...rz.de>,
        Petr Uzel <petr.uzel@...e.cz>, Thomas Biege <thomas@...e.de>,
        Jan Kaluža <jkaluza@...hat.com>
Subject: Re: CVE Request -- logrotate -- nine issues

----- Original Message -----
> On Mon, Mar 07, 2011 at 01:21:05PM +0100, Jan Kaluža wrote:
> 
> > 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.
> 
> "--override-unsafe-directory-check" perhaps? Make it a long option,
> so that there is no doubt that the user is doing something that's
> potentially dangerous.
> 
> (I am following this discussion with great interest.)
> 

It seems there is now a consensus on this (at least that's how I'm reading
it). Here is what I plan to do with CVE ids unless someone speaks up.

As best as I can tell, logrotate only needs a CVE id for this:

    8) Issue #8: logrotate: TOCTOU race condition by creation of new files
       (between opening the file and moment, final permissions have been
       applied) [information disclosure]

        It was found that logrotate utility used insecure default
        permissions, when creating of new files (time-of-check,
        time-of-use, TOCTOU race condition).  In some specific
        configurations, a local attacker could use this flaw to open the
        new file before the final permissions have been applied, leading to
        disclosure of sensitive information. A different vulnerability
        than:
        [1] https://bugzilla.redhat.com/show_bug.cgi?id=680787 (Issue #1)

        References:
        [14] https://bugzilla.redhat.com/show_bug.cgi?id=680798

        Source code background (issue reason):
        [15] https://bugzilla.redhat.com/show_bug.cgi?id=680798#c3

We then will need to assign IDs for various broken uses of /var/log (If
someone has a list of the currently known ones, please pass it along)

What does everyone think?

Thanks.

-- 
    JB

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.