A vulnerability was found in logrotate in how the state file is created. The state file is used to prevent parallel executions of multiple instances of logrotate by acquiring and releasing a file lock. When the state file does not exist, it is created with world-readable permission, allowing an unprivileged user to lock the state file, stopping any rotation. This flaw affects logrotate versions before 3.20.0.

The default configuration of logrotate on SUSE openSUSE Factory uses root privileges to process files in directories that permit non-root write access, which allows local users to conduct symlink and hard link attacks by leveraging logrotate's lack of support for untrusted directories, as demonstrated by directories for the (1) cobbler, (2) inn, (3) safte-monitor, and (4) uucp packages.

The default configuration of logrotate on Gentoo Linux uses root privileges to process files in directories that permit non-root write access, which allows local users to conduct symlink and hard link attacks by leveraging logrotate's lack of support for untrusted directories, as demonstrated by directories under /var/log/ for packages.

The default configuration of logrotate on Debian GNU/Linux uses root privileges to process files in directories that permit non-root write access, which allows local users to conduct symlink and hard link attacks by leveraging logrotate's lack of support for untrusted directories, as demonstrated by /var/log/postgresql/.

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 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.

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.