Opened 7 years ago

Last modified 7 years ago

#1134 new enhancement

CVE-2016-1247

Reported by: mikhirev@… Owned by:
Priority: major Milestone:
Component: nginx-core Version: 1.9.x
Keywords: Cc:
uname -a:
nginx -V: nginx version: nginx/1.6.2
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt=-Wl,-z,relro --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_spdy_module --with-http_sub_module --with-http_xslt_module --with-mail --with-mail_ssl_module --add-module=/build/nginx-AGNHOe/nginx-1.6.2/debian/modules/nginx-auth-pam --add-module=/build/nginx-AGNHOe/nginx-1.6.2/debian/modules/nginx-dav-ext-module --add-module=/build/nginx-AGNHOe/nginx-1.6.2/debian/modules/nginx-echo --add-module=/build/nginx-AGNHOe/nginx-1.6.2/debian/modules/nginx-upstream-fair --add-module=/build/nginx-AGNHOe/nginx-1.6.2/debian/modules/ngx_http_substitutions_filter_module

Description

Hi!

Recently there was a vulnerability reported against Debian nginx package [1]. It seems to be more general and applicable to different nginx installations on various systems, so it needs to be fixed in nginx itself.

The problem is that if log file can be replaced with a symbolic link, it allows overwriting files owned by root. The solution is to perform some checks before opening log files. If (a) nginx have not dropped root privileges and (b) directory where log file is placed is writable by non-root user and (c) log file is symbolic link, nginx should decline opening it.

[1]: https://legalhackers.com/advisories/Nginx-Exploit-Deb-Root-PrivEsc-CVE-2016-1247.html

Change History (4)

comment:1 by Maxim Dounin, 7 years ago

Type: defectenhancement

Better solution would be to implement passing open file descriptors from master to workers and thus make proper log handling easier, see #376.

comment:2 by mikhirev@…, 7 years ago

Well, there is a much simpler solution: open logs with O_NOFOLLOW.

comment:3 by Maxim Dounin, 7 years ago

Or you may even disable symlinks in your OS completely. The fact is that they exists for a reason and there are multiple legitimate uses.

comment:4 by mikhirev@…, 7 years ago

Of course I agree that symlinks exist for good reason, but I don't see any reason to use them for log files. Administrator always can specify the path he wants in configuration file instead symlinking logs somewhere. What I suggested is just a simplest solution from CERT recommendation POS01-C:
https://www.securecoding.cert.org/confluence/display/c/POS01-C.+Check+for+the+existence+of+links+when+dealing+with+files

Note: See TracTickets for help on using tickets.