Bug 785204

Summary:	SECURITY: /etc/logrotate.d/httpd starts httpd if it is not running at the time of log rotation
Product:	Red Hat Enterprise Linux 6	Reporter:	Eduard Vopicka <eduard.vopicka>
Component:	httpd	Assignee:	Joe Orton <jorton>
Status:	CLOSED NOTABUG	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	6.2	CC:	prc, thoger
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-01-31 17:15:44 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Eduard Vopicka 2012-01-27 15:52:05 UTC

Description of problem:

/etc/logrotate.d/httpd starts httpd when it is not running at the time of log rotation


Version-Release number of selected component (if applicable):
httpd-2.2.15-15.el6.x86_64

How reproducible:

always


Steps to Reproduce:

# Verify you have working httpd configuration
service httpd start
service httpd status
ps ax|grep httpd

# httpd should be running at this point

# stop httpd and verify it is not running
service httpd stop
service httpd status
ps ax|grep httpd

# At this point httpd should not be running. Wait till the next morning.

# Check if httpd is running
service httpd status
ps ax|grep httpd

and you should see that httpd is running now.

  
Actual results:

httpd is running

Expected results:

httpd should not be running. Logrotate action should not start httpd if httpd is not already running at the time of log rotation.

Additional info:

I am considerinng this to be not only functional, but primarily SECURITY problem. This automa[tg]ically started httpd may have not secured enough configuration and/or may allow unwanted access to data.

This happens because of "/usr/sbin/apachectl graceful" is invoked in the postrotate section of /etc/logrotate.d/httpd. And "apachectl graceful" does not care and starts httpd if it is not running

It is my opinion that this should be fixed in /etc/logrotate.d/httpd only and the usual (and maybe bad) behavior of "apachectl graceful" probably should not be changed.

Comment 2 Tomas Hoger 2012-01-29 15:10:21 UTC

AFAICS, default logrotate config for httpd invokes "service httpd reload" rather than "apachectl graceful":

/var/log/httpd/*log {
    missingok
    notifempty
    sharedscripts
    delaycompress
    postrotate
        /sbin/service httpd reload > /dev/null 2>/dev/null || true
    endscript
}

Reload does not seem to start httpd when it's not running:

# /sbin/service httpd stop
Stopping httpd:                                            [  OK  ]

# /sbin/service httpd status
httpd is stopped

# /sbin/service httpd reload
Reloading httpd:                                           [FAILED]

# /sbin/service httpd status
httpd is stopped

Customized logrotate config with graceful possibly?

Comment 3 Eduard Vopicka 2012-01-30 01:50:20 UTC

Thanks you for pointing this out. And sorry for raising this up as a bug.

In fact, I have only single system with httpd installed but disabled via chkconfig. And quick check has revealed that of all apaches I am able to access at this night time only two have the now-known-crippled logrotate script. Tripwire has been installed on both these systems before they were put into production and it does not show any change of /etc/logrotate.d/httpd, so the change is probably not sign of any intrusion. I am really curious about what our backup system will tell me about the last backup date of /etc/logrotate.d/httpd.

But anyway, now I have both systems with cripped /etc/logrotate.d/httpd on totally isolated network segment for analysis and have both reinstalled from trusted system image on the production segment.

Thank you for your effort.

Comment 4 Tomas Hoger 2012-01-30 14:38:25 UTC

I did not mean to imply graceful in your config is there due to a compromise, it sounds more likely that config got changed when the system was installed (possibly re-using tested configuration from some other system, where httpd is expected to be running).

Comment 5 Joe Orton 2012-01-31 17:15:44 UTC

Eduard, I recommend you contact Red Hat Support if you have further issues or need further assistance diagnosing this problem.  I'm closing out this bug.