Bug #74860 [Com]: Uncaught exceptions not being formatted properly when error_log set to "syslog"
| From: | philipp at redfish-solutions dot com | Date: | Sat, 05 Aug 2017 00:02:31 +0000 |
| Subject: | Bug #74860 [Com]: Uncaught exceptions not being formatted properly when error_log set to "syslog" | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-210502@lists.php.net to get a copy of this message | ||
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:
> THAT IS HOW SECURITY WORKS and not by a sloppy "there should not happen something
> bad" idiot attitude
It's not sloppy. It's realistic.
I've literally fixed thousands of potential exploits in my lifetime. At one point, I was doing
it full-time.
There's a limited amount of bandwidth to secure systems, and you need to expend your energy and
resources wisely.
There are an infinite number of files which could theoretically have control characters dumped into
them via an equally infinite number of vectors.
They can't all be fixed.
What can be fixed is the singular vulnerability in Xterm.
You also can't put a bandaid over the symptom while calling the cause simultaneously fixed.
That's not security. That self-delusion.
Previous Comments:
------------------------------------------------------------------------
[2017-08-04 22:05:03] philipp at redfish-solutions dot com
> The fix is in the wrong place. The fix should be to modify the php_syslog function to conform
> with expectations. I believe a more robust fix would be preferable ...
You know that there is no actual function called php_syslog(), right? And that it's a macro
which either points to std_syslog() or else to syslog() directly. And both of those are in external
libraries. So how would I fix that?
------------------------------------------------------------------------
[2017-08-04 21:58:34] spam2 at rhsoft dot net
GDAMNED:it does not matter where the vulnerability is - make sure that f***g Logfiles don't
contain control chars at all - THAT IS HOW SECURITY WORKS and not by a sloppy "there should not
happen something bad" idiot attitude
------------------------------------------------------------------------
[2017-08-04 21:49:19] philipp at redfish-solutions dot com
I'm looking at:
https://www.acunetix.com/vulnerabilities/web/apache-error-log-escape-sequence-injection-vulnerability
Where it says:
"This version of Apache is vulnerable to escape character sequences injection into error
log.This problem may be exploited when a vulnerable terminal emulator is used."
emphasis on the last 5 words. The vulnerability is the broken terminal emulator.
Likewise for:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4487
------------------------------------------------------------------------
[2017-08-04 21:41:25] spam2 at rhsoft dot net
you clearly did not understand what I was talking about: with control chars in a text file it is
possible that a simple "cat filename" leads to execute code sequences in the shell and
some time ago there was even a CVE for mod_security lacking proper escapeing leading to execute code
by just display the log file
------------------------------------------------------------------------
[2017-08-04 18:54:08] philipp at redfish-solutions dot com
> and error_log() should also take care of non-printable characters because otherwise it's
> possible to trigger logfiles with control chars and that can lead in "cat logifle"
> unexpected executes code from untrusted input part of the logging
I'm not sure that's a real problem. Why would anyone be executing log files?
And even if they did, it's not enough to have "magic contents" in a file to be a
problem, they also have to be at the correct offset in the file... which would be extremely hard to
guarantee for a log file, since you can't know in advance what's already been logged to
that file.
This seems like a non-issue.
------------------------------------------------------------------------
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