Bug 680790 - logrotate: TOCTOU race condition by creation of log files after rotation (ability to change file owner / mode on arbitrary system files)
logrotate: TOCTOU race condition by creation of log files after rotation (abi...
Status: CLOSED NOTABUG
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
public=20110213,reported=20110213,sou...
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-27 14:24 EST by Jan Lieskovsky
Modified: 2016-03-04 06:29 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-03-11 01:30:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jan Lieskovsky 2011-02-27 14:24:39 EST
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).
Comment 3 Jan Lieskovsky 2011-03-03 04:31:33 EST
Clarified flaw details from Stefan Fritsch of Debian Security Team:
===================================================================

Here the race condition is between the rename

950 if (!debug && rename(oldName, newName)) {

and the creation of the new file at

1117 fd = createOutputFile(log->files[logNum], O_CREAT | O_RDWR,
&sb);

If an attacker can link a file into place in that race period, the
permissions of that file will be changed. It is not necessary for the
attacker to have write or chmod permissions on the log file. The fix
is to use O_EXCL.

Note You need to log in before you can comment on or make changes to this bug.