Re: Nginx (Debian-based + Gentoo distros) - Root Privilege Escalation [CVE-2016-1247 UPDATE]

[Carlos Alberto Lopez Perez <clopez () igalia com>]

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.

Attachment: signature.asc
Description: OpenPGP digital signature