Edit report at https://bugs.php.net/bug.php?id=74860&edit=1
ID: 74860
Comment by: spam2 at rhsoft dot net
Reported by: philipp at redfish-solutions dot com
Summary: Uncaught exceptions not being formatted properly
when error_log set to "syslog"
Status: Open
Type: Bug
Package: Output Control
Operating System: linux 4.9.30
PHP Version: 7.1.6
Block user comment: N
Private report: N
New Comment:
> I don't think there is an overall conses on how to handle this,
> the RFC suggests that a receiver has to deal with that if
> non-printable (non-allowed) characters are used in the MSG part
yeah, that's how to create security issues as mod_rewrite did in case one did "cat
logfile" leading to execute commands because of not properly filtered control chars
Previous Comments:
------------------------------------------------------------------------
[2017-07-05 23:25:22] philipp at redfish-solutions dot com
For what it's worth, I'm using syslog-ng 3.9.1 on my system.
In the case of using rsyslog, the message would have been reformatted as it was written to disk with
newlines being replaced literally with "\012" (i.e. an escaped octal sequence). Also not
desirable.
------------------------------------------------------------------------
[2017-07-05 23:18:47] philipp at redfish-solutions dot com
> this patch tries to address the existing flaw
> but: this patch turns a single MSG into multiple messages while keeping invalid characters.
The patch is a very specific point-fix: it attempts to handle the known case of embedded newlines
being generated by built-in code itself. Newlines are a specific issue and how to handle them in the
case of syslog is tacitly understood: if syslog is a line-oriented logging protocol (which it
definitely is), then it must be sent multiline messages as multiple single lines.
The larger, more abstract problem of how to handle *any* control character is not what is being
addressed.
> I don't think there is an overall conses [sic] on how to handle this, the RFC suggests
> that a receiver has to deal with that if non-printable (non-allowed) characters are used in the MSG
> part.
That's entirely irrelevant: this bug is how the sender should properly format his messages, not
how the receiver should handle malformed messages as you purport.
We most certainly do know how to handle things on the sending side: send well-formed messages.
There's no equivocation on this point.
------------------------------------------------------------------------
[2017-07-05 22:12:25] hanskrentel at yahoo dot de
The MSG can not contain any non-printable characters (below %d32, higher than %d126).
currently those invalid MSG characters are not treated in any way, there is no input validation.
this patch tries to address the existing flaw.
but: this patch turns a single MSG into multiple messages while keeping invalid characters.
I don't think there is an overall conses on how to handle this, the RFC suggests that a
receiver has to deal with that if non-printable (non-allowed) characters are used in the MSG part. I
can imagine similar things when using UTF-8 in the MSGs containing octet sequences leaving the
%d32-126 range.
------------------------------------------------------------------------
[2017-07-05 20:43:08] philipp at redfish-solutions dot com
Citing RFC 3164:
4.1.3 MSG Part of a syslog Packet
The MSG part will fill the remainder of the syslog packet. This will
usually contain some additional information of the process that
generated the message, and then the text of the message. There is no
ending delimiter to this part. The MSG part of the syslog packet
MUST contain visible (printing) characters. [...]
------------------------------------------------------------------------
[2017-07-05 20:36:39] philipp at redfish-solutions dot com
Description:
------------
I'm using php-7.1.6 on Linux (LEDE master). During development, I had an uncaught exception
which generated the diagnostic:
2017-07-05T11:56:20-06:00 PowercodeBMU Powercode: Error: Call to undefined function fetch() in
/www/lib/php/LogController.php:48
Stack trace:
#0 /tmp/foo.php(7): LogIterator->valid()
#1 {main}
i.e. 4 lines of text with embedded newlines. syslog() doesn't handle this correctly, as each
line is supposed to be prefixed with a timestamp, hostname, and tag... but only the first line is
formatted correctly because syslog() is handling the buffer as a single string.
The correct behavior is to explode this message on newlines and then write each part to syslog
individually.
My php.ini file contained:
error_log = "syslog";
Test script:
---------------
Just about any uncaught exception should trigger this.
Expected result:
----------------
Correct logging should look like:
2017-07-05T11:56:20-06:00 PowercodeBMU Powercode: Error: Call to undefined function fetch() in
/www/lib/php/LogController.php:48
2017-07-05T11:56:20-06:00 PowercodeBMU Powercode: Stack trace:
2017-07-05T11:56:20-06:00 PowercodeBMU Powercode: #0 /tmp/foo.php(7): LogIterator->valid()
2017-07-05T11:56:20-06:00 PowercodeBMU Powercode: #1 {main}
note that each line is prefixed identically.
Actual result:
--------------
Per description.
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=74860&edit=1