Opened 8 years ago
Last modified 8 years ago
#1134 new enhancement
CVE-2016-1247
| Reported by: | 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 , 8 years ago
| Type: | defect → enhancement |
|---|
comment:3 by , 8 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 , 8 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
Better solution would be to implement passing open file descriptors from master to workers and thus make proper log handling easier, see #376.