php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #73569 Setting internal_encoding to empty can lead to PHP warnings
Submitted: 2016-11-21 02:36 UTC Modified: 2021-04-11 04:22 UTC
Votes:2
Avg. Score:3.5 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:2 (100.0%)
From: sam dot hemelryk at totaralearning dot com Assigned: cmb (profile)
Status: No Feedback Package: Output Control
PHP Version: 5.6.28 OS: OSX + Ubuntu tested
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: sam dot hemelryk at totaralearning dot com
New email:
PHP Version: OS:

 

 [2016-11-21 02:36 UTC] sam dot hemelryk at totaralearning dot com
Description:
------------
Important:
----------
Marked as a security issue because visually it appears that a buffer overflow is occurring, occasionally leading to file content being displayed as part of the warning in PHP 5.6.18 and greater.
My apologies if this does not warrant a security report, feel free to downgrade.


Summary:
--------
Setting internal_encoding to an empty string will cause unexpected charset warnings when calling htmlspecialchars.


Affects:
--------

* 5.6.16 (OSX)
    Partial, warning is printed but error contains no unexpected content.
    "PHP Warning:  htmlspecialchars():  in index.php on line 7"
* 5.6.18 (OSX)
    "PHP Warning:  htmlspecialchars(): charset `�`�' not supported, assuming utf-8 in index.php on line 62"
* 5.6.27_1 (Ubuntu)
    "PHP Warning:  htmlspecialchars(): charset `�`T' not supported, assuming utf-8 in index.php on line 62"
* 5.6.27_4 (OSX)
    "PHP Warning:  htmlspecialchars(): charset `�`T' not supported, assuming utf-8 in index.php on line 62"
* 5.6.28_1 (Ubuntu)
    "PHP Warning:  htmlspecialchars(): charset `' not supported, assuming utf-8 in index.php on line 62"

Security note: 5.6.18 and above may include script source code in the warning.
The following example illustrates one such occurrence with the test scripts provided (retrieved from console log):

Warning: htmlspecialchars(): charset ` same. * 2. In one browser visit index.php and confirm no warning. Refresh a few times for certainty. * 3. In a second browser visit bust.php. * 4. Back in the first browser refresh a few times and confirm you see the warning. * * Affects: * * 5.6.16 (OSX) * - Partial, warning is printed but error contains no unexpected content. * "PHP Warning: htmlspecialchars(): in index.php on line 7" * 5.6.18 (OSX) * "PHP Warning: htmlspecialchars(): charset `�`�' not supported, assuming utf-8 in index.php on line 7" * 5.6.27_1 (Ubuntu) * "PHP Warning: htmlspecialchars(): charset `�`T' not supported, assuming utf-8 in index.php on line 7" * 5.6.27_4 (OSX) * "PHP Warning: htmlspecialchars(): charset `�`T' not supported, assuming utf-8 in index.php on line 7" * 5.6.28_1 (Ubuntu) * "PHP Warning: htmlspecialchars(): charset `' not supported, assuming utf-8 in index.php on line in /private/var/www/phptest/index.php on line 62


Does not affect:
----------------

* 7.0.3 (OSX)
* 7.0.10 (OSX)
* 7.1.0-rc.6_10 (OSX)


To reproduce:
-------------
This can be reproduced with a single test file, however for clarity I will use two test files, index.php and bust.php available here: https://gist.github.com/samhemelryk/45f0d50696c6197e432894e5e1da057c

1. In terminal navigate to the location of the scripts.
2. Run: php -S 127.0.0.1:8000
3. In your browser visit to http://127.0.0.1:8000
4. Refresh the page several times and confirm you see no warnings.
5. Follow the link "Trigger the problems" (will redirect to bust.php and then back to index.php)
6. Refresh your browser a few times, you will likely get an PHP warning about htmlspecialchars charset.

Additional testing:

a) The warning in PHP 5.6.18 and above contains random content, visually looks like buffer overflow.
   1. Note the error you got.
   2. Kill the built in PHP Server and restart it exactly the same.
   3. Visit index.php and click the link.
   4. Observe the warning content has changed.
      Typically you get UTF-8 chars, however on occasion you will get code from this file or bust.php
      Filed as a security issue as oit appears possible for files containing credentials to be
      incorrectly displayed in a readable format.

b) Once triggered the condition is persistent for all users until the web server is restarted.
   1. Kill the built in PHP Server and restart it exactly the same.
   2. In one browser visit index.php and confirm no warning. Refresh a few times for certainty.
   3. In a second browser visit bust.php.
   4. Back in the first browser refresh a few times and confirm you see the warning.


Final notes:
------------

* I have tested this on both OSX, and Ubuntu, and can confirm I can reproduce reliably, albeit randomly, on both.
  Final testing before report was conducted on a clean installation of Ubuntu 16.04 using ppa:ondrej/php.
  I have not ruled out PHP modules, as such it may be relevant to note that the following modules may be
  required in order to reproduce: intl, mbstring, bcmath, zip, xsl, xmlrpc.
* This may be the same issue as experienced at https://bugs.php.net/bug.php?id=71876
  I chose to file this as a new issue as that issue is not a security concern presently and doesn't touch on
  the buffer overflow issue mentioned above.
  It also deals with a different version, one which I have determined is not affected by this exact report.
* We encountered this while locking down charset encoding in our project.
  Due to support reasons the lock down was only applied to the latest releases.
  Shortly after applying this developers started reporting these warnings.
  It took us some time to track down through the iterations of our project, isolate it, and test across multiple systems.
  For us the solution is easy, we will avoid locking down internal_encoding in our source at this time.
* This was my first report, I've attempted to be thorough, if there is anything more I should be doing should I need
  to file another report please don't hesitate to let me know.

Cheers
Sam

Test script:
---------------
https://gist.github.com/samhemelryk/45f0d50696c6197e432894e5e1da057c

Expected result:
----------------
No warning should be present, PHP documentation at http://php.net/manual/en/ini.core.php states "Available from PHP 5.6.0. This setting is used for multibyte modules such as mbstring and iconv. Default is empty. If empty, default_charset is used."

Actual result:
--------------
PHP Warning:  htmlspecialchars(): charset `�`T' not supported, assuming utf-8 in index.php on line 62

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-11-21 19:47 UTC] stas@php.net
-Type: Security +Type: Bug
 [2016-11-21 19:47 UTC] stas@php.net
Not a security issue.
 [2021-03-31 17:34 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2021-03-31 17:34 UTC] cmb@php.net
I think this issue has been fixed long ago, or can anybody still
reproduce with any of the actively supported versions[1]?

[1] <https://www.php.net/supported-versions.php>
 [2021-04-11 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 23:01:26 2024 UTC