Joe’s solution seems to fix the problem. I havent tested it yet though. I would
have been forced to patch this reguardless before bringing php 7+ into
production. His fix would be enough to protect the data provided proper config
files are enforced.
Thanks Joe! Hopefully this will be merged which would be one less thing to
maintain.
/Erik
> 17 juni 2019 kl. 21:27 skrev Björn Larsson <bjorn.x.lars...@telia.com>:
>
>> Den 2019-06-17 kl. 19:10, skrev Erik Lundin:
>> Background:
>> The latest version of PHP seems to handle fatal errors as exceptions which
>> results in stack traces being logged. Stack traces can potentially contain
>> sensitive information and should not be logged in a production environment.
>>
>> Test code:
>> <?php
>> function handle_password($a) {
>> does_not_exist();
>> }
>> handle_password('s3cretp4ssword');
>>
>> PHP 5.4.16:
>> Jun 17 15:58:01 server php[29650]: PHP Fatal error: Call to undefined
>> function does_not_exist() in /var/www/html/index.php on line 3
>>
>> PHP 7.4 (dev):
>> Jun 17 15:58:01 server php[18159]: PHP Fatal error: Uncaught Error: Call to
>> undefined function does_not_exist() in /var/www/html/index.php:3#012Stack
>> trace:#012#0 /var/www/html/index.php(5):
>> handle_password('s3cretp4ssword')#012#1 {main}#012 thrown in
>> /var/www/html/index.php on line 3
>>
>> Suggested patch:
>> Add a configuration value to be able to prevent exceptions from logging
>> stack traces.
>>
>> log_exception_trace = On/Off
>>
>> It would be optimal to have this disabled as default as novice
>> administrators would perhaps not be aware that this information would be
>> logged. For debugging purposes it would be helpful to be able to enable this
>> but maybe the default value should be set conservatively to minimize
>> unnecessary problems?
>>
>> I've added this configuration value in Zend/zend.c as the exception message
>> is compiled in Zend/zend_exceptions.c. Adding it to main/main.c would change
>> the scope from zend_compiler_globals to php_core_globals and I guess that
>> you wouldn't want to mix them?
>>
>> Link to pull request: https://github.com/php/php-src/pull/4281
>>
>> Regards, Erik Lundin
>>
> Hi,
>
> In our environment these kind of errors goes to the Apache error log.
> We have full control of the complete LAMP stack and it's only our
> ISP who can access these. So little risk for leakage of sensitive info.
>
> Now we have a large legacy code base that has been migrated from
> PHP 5.2 to PHP 7.3. Even if we have tested a lot we have had great
> usage of these kind of stack traces in the production environment.
> It helped us fixing the (hopefully) last issues. We also have a kind of
> beta site, but we didn't got enough traffic on that one to trigger the
> errors we got in production.
>
> My 50c on this subject, well aware of that having "ownership" of the
> LAMP stack is one prerequisite to not disclose sensitive info.
>
> r//Björn Larsson
