Whilst I agree that PHP is distributed for the development market, I have to disagree with your other comments. Many of the systems that get targeted and subsequently exploited in the field do so because of lax administration. How many IIS systems do you know of that are installed with all the defaults?, or perhaps the question is better posed this way, how many IIS systems do you know of that are installed in a manner other than the default settings?. Your comment about lazy administrators I think is also misguided, just think of all the systems with default passwords that never get changed, and hence lead to their exploitation. I would prefer to word your sentence "Lazy administrators turn options into opportunities". Cheers. > ---------- > From: Eric Fitzgerald[SMTP:ericat_private] > Sent: 14 May 2001 18:46 > To: PJD@portcullis-security.com; VULN-DEVat_private > Subject: Re: PHP Disclosure issue > > 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 : Tue May 15 2001 - 21:54:56 PDT