changed package,
"reflection related" does not seem to relate to "reflection in the XSS sense".

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.

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,

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

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.