Multiple vulnerabilities have been found in logrtate, no CVEs yet: https://bugzilla.redhat.com/show_bug.cgi?id=680787 : A file access race condition (time-of-check, time-of-use, TOCTOU race condition) was found in the way the logrotate utility has run the prerorate and postrotate scripts on a particular log file, for which compression of old version has been requested. A local attacker could use this flaw trick the logrotate utility to compress the file contents into user selected file, potentially leading to disclosure of sensitive information, if the logrotate utility was run on a log file, contained within attacker controllable directory. https://bugzilla.redhat.com/show_bug.cgi?id=680789 : A race condition was found in the way the logrotate utility created new copy of the original log file, when the truncation of the original log file after creation of a copy (copytruncate) behavior was requested in the configuration file. A local attacker could use this flaw to truncate arbitrary system file (if logrotate was run under privileged user account, root) by tricking the logrotate utility to run on a log file, contained within user controllable directory. https://bugzilla.redhat.com/show_bug.cgi?id=680790 : 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 (if the logrotate utility was run under privileged user, root), when the original file mode, specified in the logrotate configuration file, allowed the attacker to acces / change the mode on the newly created log file. https://bugzilla.redhat.com/show_bug.cgi?id=680792 : 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 attacks. https://bugzilla.redhat.com/show_bug.cgi?id=680795 : 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 attacks and send arbitrary system files (if the logrotate utility was run under privileged system user, root) to the selected email recipient. https://bugzilla.redhat.com/show_bug.cgi?id=680796 : 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. https://bugzilla.redhat.com/show_bug.cgi?id=680797 : 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. https://bugzilla.redhat.com/show_bug.cgi?id=680798 : It was found that logrotate utility used insecure default permissions, when creating of new files (time-of-check, time-of-use, TOCTOU race condition). A local attacker could use this flaw to conduct symlink attacks, leading to disclosure of sensitive information. https://bugzilla.redhat.com/show_bug.cgi?id=680799 : 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.
Rating A1 because of possible shell command injection (https://bugzilla.redhat.com/show_bug.cgi?id=680796).
FYI, there are ebuilds and eclasses that create user/group-writable directories in /var/log and enable logrotate to handle the log files there. dev-db/mysql (mysql.eclass) and media-sound/murmur, for example.
I've added app-admin/logrotate-3.7.9-r1 with the patches from the tree upstream bugs that were not closed as "NOTABUG". These correspond to CVE-2011-1154, CVE-2011-1098 and CVE-2011-1155 (which includes the shell injection). RedHat classified this update as "Moderate".
(In reply to comment #3) > I've added app-admin/logrotate-3.7.9-r1 with the patches from the tree upstream > bugs that were not closed as "NOTABUG". Great, thanks. Arches, please test and mark stable: =app-admin/logrotate-3.7.9-r1 Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86"
Stable for HPPA.
x86 stable. Thanks
amd64 done
ppc done
ppc64/ia64 stable
alpha/arm/s390/sh/sparc stable
Thanks, folks. GLSA request filed.
CVE-2011-1155 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-1155): The writeState function in logrotate.c in logrotate 3.7.9 and earlier might allow context-dependent attackers to cause a denial of service (rotation outage) via a (1) \n (newline) or (2) \ (backslash) character in a log filename, as demonstrated by a filename that is automatically constructed on the basis of a hostname or virtual machine name. CVE-2011-1154 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-1154): The shred_file function in logrotate.c in logrotate 3.7.9 and earlier might allow context-dependent attackers to execute arbitrary commands via shell metacharacters in a log filename, as demonstrated by a filename that is automatically constructed on the basis of a hostname or virtual machine name. CVE-2011-1098 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-1098): Race condition in the createOutputFile function in logrotate.c in logrotate 3.7.9 and earlier allows local users to read log data by opening a file before the intended permissions are in place.
app-admin/logrotate-3.7.9-r1 is no longer in the tree. Can this bug be closed?. Thanks.
(In reply to comment #13) > > Can this bug be closed?. Thanks. Hi, Chema, no. We need to publish a GLSA before the bug can be closed.
This issue was resolved and addressed in GLSA 201206-36 at http://security.gentoo.org/glsa/glsa-201206-36.xml by GLSA coordinator Stefan Behte (craig).
