Opened 7 years ago

Last modified 7 months ago

#191 accepted defect

literal newlines logged in error log

Reported by: www.google.com/accounts/o8/id?id=AItOawk6TGezIKBXjmkDc8Vq2QUV3mM5CHUou-I 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 Changed 7 years ago by www.google.com/accounts/o8/id?id=AItOawk6TGezIKBXjmkDc8Vq2QUV3mM5CHUou-I

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...

comment:2 Changed 7 years ago by mdounin

  • Status changed from new to 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 Changed 7 years ago by www.google.com/accounts/o8/id?id=AItOawk6TGezIKBXjmkDc8Vq2QUV3mM5CHUou-I

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...

comment:4 Changed 7 months ago by mdounin

See also #1756.

Note: See TracTickets for help on using tickets.