php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Sec Bug #66475 XSS in error_reporting
Submitted: 2014-01-12 23:20 UTC Modified: 2014-01-15 20:55 UTC
From: fabien_duchene_p0wn3r at car-online dot fr Assigned:
Status: Not a bug Package: *General Issues
PHP Version: 5.5.8 OS: all
Private report: No CVE-ID: None
 [2014-01-12 23:20 UTC] fabien_duchene_p0wn3r at car-online dot fr
Description:
------------
Since the filename of a file may be tainted by the user (it is the case in many applications, e.g. SAN devices), Any error reporting generated by PHP should not print the script filename without sanitizing it first.

The current implementation permits Cross Channel Scripting (XCS), a particular case of stored/type-2 Cross Site Scripting (XSS).


===========
php55 --ini
Configuration File (php.ini) Path: /opt/local/etc/php55
Loaded Configuration File:         (none)
Scan for additional .ini files in: /opt/local/var/db/php55
Additional .ini files parsed:      (none)
===========
php55 -i #(extract)
phpinfo()
PHP Version => 5.5.8

Configure Command =>  './configure'  '--prefix=/opt/local' '--mandir=/opt/local/share/man' '--infodir=/opt/local/share/info' '--program-suffix=55' '--includedir=/opt/local/include/php55' '--libdir=/opt/local/lib/php55' '--with-config-file-path=/opt/local/etc/php55' '--with-config-file-scan-dir=/opt/local/var/db/php55' '--disable-all' '--enable-bcmath' '--enable-ctype' '--enable-dom' '--enable-fileinfo' '--enable-filter' '--enable-hash' '--enable-json' '--enable-libxml' '--enable-pdo' '--enable-phar' '--enable-session' '--enable-simplexml' '--enable-tokenizer' '--enable-xml' '--enable-xmlreader' '--enable-xmlwriter' '--with-bz2=/opt/local' '--with-mhash=/opt/local' '--with-pcre-regex=/opt/local' '--with-libxml-dir=/opt/local' '--with-zlib=/opt/local' '--without-pear' '--disable-cgi' '--enable-cli' '--disable-fpm' '--with-libedit=/opt/local'

===========

Test script:
---------------
<?php

/* 
the file has to be named: (without the quotes)
"test2<img src=x onerror=alert(1)>.php"
*/

ini_set("error_reporting",E_ALL);
ini_set("display_errors", 1);
(1/0);

?>

Expected result:
----------------
Warning: Division by zero in /xxx/test2&lt;img src=x onerror=alert(1)&gt;.php on line 4

Call Stack:
    0.0002     638272   1. {main}() /xxx/test2&lt;img src=x onerror=alert(1)&gt;.php:0



Actual result:
--------------
Warning: Division by zero in /xxx/test2<img src=x onerror=alert(1)>.php on line 4

Call Stack:
    0.0002     638272   1. {main}() /xxx/test2<img src=x onerror=alert(1)>.php:0



Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-01-13 02:30 UTC] fabien_duchene_p0wn3r at car-online dot fr
-Package: Reflection related +Package: *General Issues
 [2014-01-13 02:30 UTC] fabien_duchene_p0wn3r at car-online dot fr
changed package,
"reflection related" does not seem to relate to "reflection in the XSS sense".
 [2014-01-13 08:51 UTC] stas@php.net
-Status: Open +Status: Not a bug
 [2014-01-13 08:51 UTC] stas@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Debug error reporting is a debugging feature which should not be enabled in a production server. Additionally, since the user himself chooses the filename, it is not an XSS - he could as well just print the javascript, no change of context happens here.
 [2014-01-15 11:02 UTC] fabien_duchene_p0wn3r at car-online dot fr
Hi,

> Debug error reporting is a debugging feature which should not be enabled in a production server. 
Following your reasoning, if there is a memory corruption vulnerability in a PHP module that is not activated by default in the php.ini-recommended, then this would not be a vulnerability?


> Additionally, since the user himself chooses the filename, it is not an XSS - he could as well just print the javascript, no change of context happens here.
I am unsure what you refer by "print the javascript" (if you mean the filename could be "<script>alert(1)</script>.php", the slash prevents this name from working, and I do not think that urldecode() is called when printing the filename in error_reporting() ; if you mean that the attacker could do "print('<script>...');" I do not hypothesize this attacker capability, i.e. the attacker cannot craft the web application to run PHP code he controls).

In the scenario I described:
 - an application developer wrote a code that trigger a runtime info/warning/notice/error reported by error_reporting(). The PHP code is not controlled by the attacker.
 - in this hypothetical application the user has the ability to RENAME a PHP file that is written by the developer. It means that there will be an HTTP request in which in a GET or POST parameter the attacker specifies the filename I indicated
 - due to the runtime error, the TAINTED name of the file, and the fact that  error_reporting is NOT SANITIZING its output and is REFLECTING the filename which was TAINTED before, we have an XCS (Cross Channel Scripting).

I advise you to look at the XCS talk by Elie Bursztein:
http://www-verimag.imag.fr/~async/CCIS/talks_09/Elie_Bursztein.pdf

On the proof of concept that I provided you, Google Chrome indeed detects this as Type-1 (reflected) XSS.


Best,
 [2014-01-15 11:35 UTC] johannes@php.net
1) if errors are reported to end users on a production system this, at least, is a leak of information and shouldn't happen, error reporting should be properly configured on production machines

2) if an application allows arbitrary renames the security concept should be rethought

3) we know little to nothing about the filesystem encoding etc. escaping the names using output encoding might break the filename making the reference of that debugging information useless
 [2014-01-15 20:55 UTC] stas@php.net
The simple rule is this - NEVER enable debug output on production servers. There's never a good reason to do it. Just don't. If you need error tracking, we have logs for that.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 14 07:01:27 2024 UTC