Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos



Vulnerability Development: Re: PHP Disclosure issue

Re: PHP Disclosure issue

From: Kevin J. Menard, Jr. <kmenard_at_WPI.EDU>
Date: Tue, 15 May 2001 09:36:15 -0400

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_at_portcullis-security.com>
To: <PEN-TEST_at_securityfocus.com>; <VULN-DEV_at_securityfocus.com>
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
Received on May 16 2001
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]