I guess my point has been missed. Many applications/systems have options such as debug mode, verbose or php_info(), all of which are invaluable during development/debugging. Whilst I am not saying these are vulnerabilities, I am saying that these should not be left on in production environments as they often disclose unnecessary or important information. The difference being that whilst this is not a directly exploitable vulnerability, it discloses information specific to the system that allows a more focused approach which could lead to the system being exploited. Further to all of this I do not believe that the developers are responsible as they have clearly stated in their response that it is documented, hence my point about the administrator rather than the developer. Finally, the use of errors to produce vulnerabilities is well known and well documented, even as far back as Bletchley Park and the Enigma, some of Turin's theorys and in fact the basis for Colossus was on the processing of errors. Cheers > ---------- > From: Kevin J. Menard, Jr.[SMTP:kmenardat_private] > Reply To: Kevin J. Menard, Jr. > Sent: Tuesday, May 15, 2001 2:36 PM > To: vuln-devat_private > Subject: Re: PHP Disclosure issue > > Would you then consider the php_info() function to be a security flaw? > I don't > consider this to be a vulnerability discovered. Anyone who's > developed with > language knows what kind of information is spit out on errors. > > ----- 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Kevin > >
This archive was generated by hypermail 2b30 : Thu May 17 2001 - 12:31:38 PDT