Opened 12 years ago

Last modified 8 months 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/ --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


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:, server: , request: "GET /%0a%0a%0ahtml/ HTTP/1.1", host:

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 (7)

comment:1 by Paul Henson, 12 years ago

Similar issues in other software packages have been considered security issues and assigned CVE's:

Any chance of getting this fixed?


comment:2 by Maxim Dounin, 12 years ago

Status: newaccepted

From security point of view we don't consider this to be a problem (and, actually, there is already CVE assigned, see It will likely be fixed though to facilitate automatic error log parsing.

comment:3 by Paul Henson, 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.


comment:4 by Maxim Dounin, 5 years ago

See also #1756.

comment:5 by Maxim Dounin, 2 years ago

See also #2340.

comment:6 by mozai@…, 2 years ago

With %22 and %OA, this could be used to forge error messages in the log. Possible exploit: making it seem like an innocent party is launching attacks.

comment:7 by Maxim Dounin, 8 months ago

See also #2549.

Note: See TracTickets for help on using tickets.