Feature #3268: Regular UTF-8 characters are escaped in error log - Lighttpd - lighty labs

Actions

Copy link

Feature #3268

closed

Regular UTF-8 characters are escaped in error log

Added by vpupkin 3 months ago. Updated 2 months ago.

Status:

Fixed

Priority:

Normal

Category:

mod_fastcgi

Target version:

1.4.77

ASK QUESTIONS IN Forums:

Description

Some localized software sometimes sends localized error messages in server error log, and Lighttpd makes these errors extremally hard to read. Maybe there should be an option to prevent escaping of regular (printable) UTF-8 characters. Or an option to disable escaping completely.

Here's a simple way to reproduce the issue:

Lighttpd configuration for PHP:

fastcgi.server += ( ".php" =>
        ((
                "bin-path" => "/usr/bin/php-cgi",
                "socket" => "/run/lighttpd/php.socket",
                "max-procs" => 1,
                "bin-environment" => (
                        "PHP_FCGI_CHILDREN" => "2",
                        "PHP_FCGI_MAX_REQUESTS" => "10000" 
                ),
                "bin-copy-environment" => (
                        "PATH", "SHELL", "USER" 
                ),
                "broken-scriptfilename" => "enable" 
        ))
)

$ cat /var/www/test.php
<?php
error_log('Це тест');
?>

$ curl http://localhost/test.php
<pre>
This will produce a log entry like this:
<pre>
2024-09-29 01:34:28: (mod_fastcgi.c.443) FastCGI-stderr:\xd0\xa6\xd0\xb5 \xd1\x82\xd0\xb5\xd1\x81\xd1\x82
</pre>

Actions

Copy link

Updated by gstrauss 3 months ago · Edited

Tracker changed from Bug to Feature
Description updated (diff)

This is intentional behavior in lighttpd to address CVE-2015-3200 (see lighttpd bug #2646)
Anything which is non-printable ASCII is encoded for logging. This has been the behavior in lighttpd since lighttpd 1.4.36, released in July 2015.

The feature request you are making is over 9 years after CVE-2015-3200. As this is not a frequent request, this does not feel like something which is an impediment to too many other people. Those affected can redirect their error logging to a local log rather than sending the log over the FastCGI error stream. After all, an application log is an application log and belongs in the specific PHP application log for that specific PHP application more than the trace belongs in the lighttpd error log.

Error logs may contain user-supplied data and that data might be malicious. It is unlikely that the average PHP developer is going to safely encode all strings passed to PHP error_log(). Therefore, lighttpd must do some encoding to the string before writing the string to the lighttpd error log. Validating whether or not the string is proper UTF-8 (and not invalid UTF-8) would be additional CPU work versus the current behavior of encoding all non-printable ASCII (which includes multi-byte UTF-8 sequences with the high bit set on each byte).

When ASCII is expected, seeing the encodings in the log may be indicative of someone trying to use UTF-8 characters which "look like" ASCII characters to try a phishing attack on someone else. However, for those whose languages are largely multi-byte UTF-8, different behavior might be desirable for the error log. As above, an existing workaround is to write such logs to a PHP application-specific log, encoding the logs as you see fit.

Maybe there should be an option to prevent escaping of regular (printable) UTF-8 characters.

That sounds more like a feature request than a bug, yet you filed this issue incorrectly as a bug. (I changed it to a Feature request.)

The code in question can be found in src/buffer.c:buffer_append_string_c_escaped()

I'll think about this feature request. Please keep in mind that lighttpd is written in C, and C that is tuned for performance. lighttpd is much, much faster than PHP.

Or an option to disable escaping completely.

No. See CVE-2015-3200. There are similar CVEs for other web server and network daemons where malicious actors could potentially initiate attacks through unescaped logs.

Actions

Copy link

Updated by gstrauss 3 months ago

Status changed from New to Patch Pending
Target version changed from 1.4.xx to 1.4.77

I have created an option to enable UTF-8 without C-escaping in the error log. However, there are some security caveats and this will not be the default behavior.

To use this feature, it will need to be enabled in lighttpd.conf:
server.feature-flags += ("server.errorlog-utf8" => "enable")

Please read the details in the commit message, which will be linked below when the commit reaches the lighttpd git master branch.

Actions

Copy link