[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 13 Jan 2017 19:26:33 +0100
From: Carlos Alberto Lopez Perez <clopez@...lia.com>
To: oss-security@...ts.openwall.com
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/ld.so.preload
>>
>> Why does logrotate "create 0640 www-data adm" over /var/log/nginx/error.log
>> removes and creates /etc/ld.so.preload ??? 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 https://trac.nginx.org/nginx/ticket/376 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]
> https://github.com/logrotate/logrotate/commit/9f19aba75079a61a913eb06748cf9aa83802c24c
>
>
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/ld.so.conf
# 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... https://trac.nginx.org/nginx/ticket/376
/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.
