Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 13 Jan 2017 19:26:33 +0100
From: Carlos Alberto Lopez Perez <>
Subject: Re: Nginx (Debian-based + Gentoo distros) - Root
 Privilege Escalation [CVE-2016-1247 UPDATE]

On 13/01/17 16:02, Thomas Deutschmann wrote:
> Hi,
> Carlos Alberto Lopez Perez wrote:
>>> --------[ /etc/logrotate.d/nginx ]--------
>>> /var/log/nginx/*.log {
>>> 	daily
>>> 	missingok
>>> 	rotate 52
>>> 	compress
>>> 	delaycompress
>>> 	notifempty
>>> 	create 0640 www-data adm
>>> 	sharedscripts
>>> 	prerotate
>>> 		if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
>>> 			run-parts /etc/logrotate.d/httpd-prerotate; \
>>> 		fi \
>>> 	endscript
>>> 	postrotate
>>> 		invoke-rc.d nginx rotate >/dev/null 2>&1
>>> 	endscript
>>> }
>>> ------------------------------------------
>> This looks to me like an issue on the logrotate side rather than on the nginx one..
>> If I have:
>> /var/log/nginx/error.log -> /etc/
>> Why does logrotate "create 0640 www-data adm" over /var/log/nginx/error.log
>> removes and creates /etc/ ??? That is shocking!
>> It should do that on /var/log/nginx/error.log, by removing that symlink
>> and creating a new empty standard file on /var/log/nginx/error.log !!
>> Dont you agree??
> No, please read the advisory again.
> Please notice that logrotate doesn't do some magic. The config tells
> logrotate to do that (logrotate itself BTW ignores symlinked files since
> v3.8.2 [1]).
> It is important to understand that logrotate is only used in that
> example to trigger nginx behavior. And attacker could also just wait for
> the system administrator to do similar actions with nginx (just a
> question of time).
> So the real "problem" is that the nginx master process runs as root and
> will change ACLs of existing files which allows an user to escalate
> privileges if that user can create files nginx will touch.
> See for more details.
> Now, given that multiple maintainers created the same problem, one could
> argue that such a change in permissions is unexpected. Nevertheless it
> is documented, so I don't blame upstream.
> See also:
> =========
> [1]

You're right. I did some tests and log-rotate refuses to rotate a symlink file

# ls -l /var/log/nginx/*
lrwxrwxrwx 1 www-data adm 16 Jan 13 18:56 /var/log/nginx/error.log -> /etc/

# logrotate --verbose /etc/logrotate.d/nginx 
reading config file /etc/logrotate.d/nginx
Handling 1 logs
rotating pattern: /var/log/nginx/*.log  after 1 days (52 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/nginx/error.log
  log /var/log/nginx/error.log is symbolic link. Rotation of symbolic links is not allowed to avoid security issues -- skipping.
not running prerotate script, since no logs will be rotated
not running postrotate script, since no logs were rotated

So the issue is than when in var/log/nginx/ there are standard logs (non symlinked)
that need to be rotated (appart from the malicious symlinked one), then logrotate
will rotate those ones, finally running the post-rotate script that send SIGURSR1
to the nginx pid.

Then nginx upon USR1 receive does the wrong thing...

/me happy to know that logrotate has a sane behaviour and avoids trying to rotate symlinks.

Download attachment "signature.asc" of type "application/pgp-signature" (884 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.