Edit report at https://bugs.php.net/bug.php?id=74860&edit=1
ID: 74860
Comment by: philipp at redfish-solutions dot com
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:
Can we please get movement on this? There's a fix attached.
Previous Comments:
------------------------------------------------------------------------
[2017-07-11 04:16:42] philipp at redfish-solutions dot com
> 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
Sorry, not familiar with that CVE. What are the details and how does it relate?
------------------------------------------------------------------------
[2017-07-05 23:26:03] spam2 at rhsoft dot net
> 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
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=74860
--
Edit this bug report at https://bugs.php.net/bug.php?id=74860&edit=1