Opened 12 years ago
Last modified 6 years ago
#191 accepted defect
literal newlines logged in error log
| Reported by: | Paul Henson | Owned by: | somebody |
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | nginx-module | Version: | 1.2.x |
| Keywords: | Cc: | ||
| uname -a: | Linux marklar-dev 3.2.11-gentoo #4 SMP Mon Jun 25 12:05:18 PDT 2012 x86_64 Intel(R) Xeon(R) CPU X6550 @ 2.00GHz GenuineIntel GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.2.2
TLS SNI support enabled configure arguments: --prefix=/usr --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error_log --pid-path=/var/run/nginx.pid --lock-path=/var/lock/nginx.lock --with-cc-opt=-I/usr/include --with-ld-opt=-L/usr/lib --http-log-path=/var/log/nginx/access_log --http-client-body-temp-path=/var/tmp/nginx/client --http-proxy-temp-path=/var/tmp/nginx/proxy --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi --http-scgi-temp-path=/var/tmp/nginx/scgi --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi --with-pcre --without-http_limit_conn_module --with-http_stub_status_module --with-http_realip_module --with-http_ssl_module --without-mail_imap_module --without-mail_pop3_module --without-mail_smtp_module --user=nginx --group=nginx |
||
Description
I noticed that when a %0a exists in the URL, nginx includes a literal
newline in the error_log when logging a file not found:
2012/07/26 17:24:14 [error] 5478#0: *8 "/var/www/localhost/htdocs/
html/index.html" is not found (2: No such file or directory), client:
1.2.3.4, server: , request: "GET /%0a%0a%0ahtml/ HTTP/1.1", host:
"test.example.com"
This wreaks havoc with my log monitoring utility 8-/.
It seems desirable to escape the newline in the log message? I tested
with the latest 1.2.2. Is there any way with the existing configuration
options to make this not happen, or any interest in updating the logging
module to handle this situation differently?
Change History (4)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
| Status: | new → accepted |
|---|
From security point of view we don't consider this to be a problem (and, actually, there is already CVE assigned, see http://nginx.org/en/security_advisories.html). It will likely be fixed though to facilitate automatic error log parsing.
comment:3 by , 12 years ago
Wow, a CVE from 2009 :). I'm really more concerned about log monitoring than security, but happened to see that newer CVE fly by on a security mailing list so thought I'd mention it.
I see you've already implemented escaping problematic characters in the access log, although I don't know how hard it would be to apply that to the error log. I poked around the code a bit but had trouble figuring out from a short initial review exactly where the log message was coming from.
Thanks...
Similar issues in other software packages have been considered security issues and assigned CVE's:
https://bugzilla.redhat.com/show_bug.cgi?id=768157
Any chance of getting this fixed?
Thanks...