Re: PHP Disclosure issue

["Eric Fitzgerald" <eric () amntv com>]

I think that where our opinions diverge is where we believe the
responsibilities of the programmer and administrators lie.  I consider
blaming PHP for this akin to blaming C for format string bugs.  Yes, C
allows format string bugs and buffer overflows, but it's the responibility
of the user to prevent those from coming into the code.  IMHO there is a
finite limit to what programming language developers are expected to dumb
down their language to prevent people from hurting themselves.

With any programming language there will always be some way for someone to
seriously hurt themselves, this happens to be a more easily changed one.
----- Original Message -----
From: <PJD () portcullis-security com>
To: <vuln-dev () securityfocus com>; <eric () amntv com>
Sent: Tuesday, May 15, 2001 2:39 AM
Subject: RE: PHP Disclosure issue


> 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:eric () amntv com]
> > Sent: 14 May 2001 18:46
> > To: PJD () portcullis-security com; VULN-DEV () securityfocus com
> > 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-TEST () securityfocus com>; <VULN-DEV () 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