Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D70F25F.6030603@redhat.com>
Date: Fri, 04 Mar 2011 15:08:31 +0100
From: Jan Lieskovsky <jlieskov@...hat.com>
To: "Steven M. Christey" <coley@...us.mitre.org>
CC: oss-security <oss-security@...ts.openwall.com>,
        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: CVE Request -- logrotate -- nine issues


Hello Josh, Steve, vendors,

   we have been contacted by Stefan Fritsch of Debian Security Team
about presence of nine security flaws in the logrotate utility
(the list is provided below).

These issues have been discovered by Florian Zumbiehl, some by
Paul Martin (the Debian logrotate maintainer) and Stefan Fritsch
in the subsequent discussion.

Could you allocate CVE ids for these issues?

Note: We would appreciate if it would be possible to allocate nine
       CVE ids (even the request amount being high) because later
       merge os some issues into one could bring yet more confusion,
       what are the issues and what would the the corresponding patches
      (thus potentially even more CVEs needed later due incomplete
       patches etc). This way the flaws are separated by impact /
       relevant code affected part.

Thanks && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team

P.S.: Apologize for such a long post, but there wasn't other way
       how to share all the information at once.

===============================================================================

1) Issue #1: logrotate: TOCTOU race condition by creating the compressed
              or copied log file (information disclosure)

       A file access race condition (time-of-check, time-of-use, TOCTOU
race condition) was found in the way logrotate determines the permissions
to newly created files when compression or copying of a log file has been
requested. If the logrotate utility was run on a log file contained within
an attacker controllable directory, a local attacker could use this flaw
to trick the logrotate utility into creating the compressed or copied file
with user selected permissions, potentially leading to disclosure of
sensitive information.

References:
[1] https://bugzilla.redhat.com/show_bug.cgi?id=680787

Source code background (issue reason):
[2] https://bugzilla.redhat.com/show_bug.cgi?id=680787#c4

Note: First CVE required.

-----------

2) Issue #2: logrotate: Race condition by creation of new files after
              renaming the previous version if compression or copy
              creation requested (arbitrary system file integrity corruption)

       A race condition was found in the way the logrotate utility created
new files after renaming the previous version if compression or creation
of a copy was requested in the configuration file. If the logrotate utility
was run on a log file contained within an attacker controllable directory,
a local attacker could use this flaw to trick the logrotate utility into
replacing arbitrary system files (if logrotate was run under privileged
user account, root) with the copied or compressed contents of a log file.

References:
[3] https://bugzilla.redhat.com/show_bug.cgi?id=680789

Source code background (issue reason):
[4] https://bugzilla.redhat.com/show_bug.cgi?id=680789#c7

Proposed patch:
[5] https://bugzilla.redhat.com/show_bug.cgi?id=680789#c3

Note: Second CVE required.

----------

3) Issue #3: logrotate: TOCTOU race condition by creation of log files after
              rotation (ability to change file owner / mode on arbitrary system
              files)

       A file access race condition (time-of-check, time-of-use, TOCTOU
race condition) was found in the way logrotate utility created the log
files after rotation, when their immediate creation ("create"
configuration option) was requested. A local attacker could use this
flaw to change file owner or mode on arbitrary system files to the file
owner and mode specified in logrotate's configuration. (if the logrotate
utility was run under privileged user, root, and logrotate was run on an
attacker controllable directory).

References:
[6] https://bugzilla.redhat.com/show_bug.cgi?id=680790

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

Note: Third CVE required.

----------

4) Issue #4: logrotate: Incorrect flags used for truncating of original log
              file in copytruncate mode (arbitrary file system truncation via
              symlink / hardlink attacks)

       It was found that logrotate utility used incorrect flags for truncation
of the original log file in place after creating a copy (copytruncate mode).
A local attacker could use this flaw to truncate arbitrary system file (if
the logrotate utility was run under privileged user account, root) by
performing symlink or hardlink attacks.

References:
[8] https://bugzilla.redhat.com/show_bug.cgi?id=680792

Note: Fourth CVE required.

------------

5) Issue #5: logrotate: Information disclosure by performing email
              notifications

       An information disclosure flaw was found in the way the logrotate
utility performed email notifications about rotating of out of existence
log files. A local attacker could use this flaw to conduct symlink or
hardlink attacks and send arbitrary system files (if the logrotate utility
was run under privileged system user, root) to the selected email recipient.

References:
[9] https://bugzilla.redhat.com/show_bug.cgi?id=680795

Note: Fifth CVE required.

----------

6) Issue #6: logrotate: Shell command injection by using the shred
              configuration directive

       A shell command injection flaw was found in the way the logrotate
utility handled shred configuration directive (intended to ensure the log
files are not readable after their scheduled deletion). A local attacker
could use this flaw to execute arbitrary system commands (if the logrotate
was run under privileged system user account, root) when the logrotate
utility was run on a log file, within attacker controllable directory.

References:
[10] https://bugzilla.redhat.com/show_bug.cgi?id=680796

Proposed patch:
[11] https://bugzilla.redhat.com/show_bug.cgi?id=680796#c5

Note: Sixth CVE required. The shred option has been introduced in logrotate
       v3.7.5.

----------

7) Issue #7:  logrotate: DoS due improper escaping of file names
               within 'write state' action

       A denial of service flaw was found in the way the logrotate utility
performed arguments sanitization, when performing the 'write state' action.
A local attacker could use this flaw to cause abort in subsequent logrotate
runs via a specially-crafted log file name.

References:
[12] https://bugzilla.redhat.com/show_bug.cgi?id=680797

Proposed patch:
[13] https://bugzilla.redhat.com/show_bug.cgi?id=680797#c3

Note: Seventh CVE required.

----------

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

Note: Eight-th CVE required.

----------

9) Issue #9: logrotate: Improper administration of log files located in
              world-writable directories

       A security flaw was found in the way the logrotate utility performed
administration of log files, located in group / world writable directories.
A local attacker could use this flaw to disclose sensitive information,
execute arbitrary code or cause a denial of service, via unintended /
unprivileged later modifications of log file directory in question.

Different vulnerability than:
[1] https://bugzilla.redhat.com/show_bug.cgi?id=680787 (Issue #1),
[2] https://bugzilla.redhat.com/show_bug.cgi?id=680789 (Issue #2),
[3] https://bugzilla.redhat.com/show_bug.cgi?id=680790 (Issue #3),
[4] https://bugzilla.redhat.com/show_bug.cgi?id=680792 (Issue #4),
[5] https://bugzilla.redhat.com/show_bug.cgi?id=680795 (Issue #5),
[6] https://bugzilla.redhat.com/show_bug.cgi?id=680796 (Issue #6),
[7] https://bugzilla.redhat.com/show_bug.cgi?id=680797 (Issue #7), and
[8] https://bugzilla.redhat.com/show_bug.cgi?id=680798 (Issue #8).

References:
[16] https://bugzilla.redhat.com/show_bug.cgi?id=680799

Note: Nineth CVE required.

===============================================================================


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.