I have to go with the Vendor on this. PHP is distributed for a development oriented market. This is a VERY simple configuration option to change for when you want to put a PHP program into production. If a server admin DOESN'T go in and change certain options in the php.ini file, they have a whole lot more to be worried about than a path disclosure. Lazy administrators don't turn options into vulnerabilities. ----- Original Message ----- From: <PJD@portcullis-security.com> To: <PEN-TESTat_private>; <VULN-DEVat_private> Sent: Saturday, May 12, 2001 11:24 PM Subject: PHP Disclosure issue > > Hi guys > > > > Recently we discovered a path disclosure vulnerability in PHP3. > > > > This issue has been discussed with the vendor, and further to this I > > have included some of the comments made by them within this mail. > > > > [Excerpt from mail to vendor] > > > > On NT 4 Server with SP5 installed, running IIS4 with PHP 3 it possible > > to request a nonexistent file and the response is an error which > > returns the wwwroot e.g. requesting the following in the browser - > > > > Exploit example: > > > > http://www.somewhere.com/notthere.php3 returns the following error in > > the browser window - > > > > Unable to open c:\<wwwroot\notthere.php3 in - on line 0 No Input file > > specified > > > > Having discussed this with the vendor, they have responded saying that > > this is a configuration error, and is simply rectified by changing a > > setting from the default within the configuration .ini file. > > > > [Snippit from the response] > > > > "I don't consider this as a security flaw; The distributed > > php.ini-dist includes the following information (for a few months, if > > not years): > > > > display_errors = On ; Print out errors (as a part of the output) ; > > For production web sites, you're strongly > > encouraged; to turn this feature off, and use error logging instead > > (see below).; Keeping display_errors enabled on a production web site > > may reveal; security information to end users, such as file paths on > > your Web server, your database schema or other information > > > > The fact that the full error information that helps you fix the > > problem is not a flaw, and is not going to change. PHP comes out of > > the box for development-oriented audience; You have to configure it > > slightly > > differently when you turn into production." > > > > [End] > > > > We see this as akin to the .idq type issue in IIS. Additionally, as > > all errors are returned to the browser it could be possible to use > > PHP3 to generate further errors that could output information on other > > web resourses within that environment. > > > > This discovery was made by John Clayton, from here at Portcullis. > > > > Regards > > > > Paul Docherty > > > > > > > > > > > > > > > > > > > > > >
This archive was generated by hypermail 2b30 : Mon May 14 2001 - 22:09:04 PDT