Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:17053
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <8D.33.29969.33A24C24@pb1.pair.com>
To: <internals@lists.php.net>
Date: Thu, 30 Jun 2005 19:18:12 +0200
Organization: bitXtender GbR
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <17091.32753.839430.671829@desk.crynwr.com>
thread-index: AcV9MzcHICuz32ibSNeHkQ5iLAqrNQAY3JCw
Subject: RE: [PHP-DEV] Bringing the 'include' discussion to an end
From: dz@bitxtender.com (=?iso-8859-1?Q?David_Z=FClke?=)
References: <17091.32753.839430.671829@desk.crynwr.com>

Fookin' Jaysus man. It _is_ a feature, _not_ a vulnerability. It starts
getting a weak point when stupid high school kiddies who "know PHP well"
start coding something ("this boy's as good as a professional, only way
cheaper") that introduces a vulnerability because they are drop dead stupid.
That's the problem. I don't care about the thousands of idiots out there who
are too dumb to avoid security leaks. If they don't know how to code
properly - who cares? It's good for you, since the company who hired the
idiot back then now knows better and will come to you. And you know how to
avoid these security problems. What's the point of this entire discussion
for Pete's sake. You can just as well stab your eye out with any fork in the
world, and that's not a reason to abolish them, right? The discussion is
stupid, and it did nothing but waste helluva lot of bandwidth.

- David 


> -----Original Message-----
> From: Russell Nelson [mailto:nelson@crynwr.com]
> Sent: Thursday, June 30, 2005 7:15 AM
> To: internals@lists.php.net
> Subject: [PHP-DEV] Bringing the 'include' discussion to an end
> 
> Okay, I'm leaving for vacation in 7 hours.  I'd like to bring the
> 'include' discussion to an end.  There have been a lot of weak points
> made, e.g. "Yeah, it's a problem; that's why we documented it".
> Rather than re-dismiss them, I'll ignore them in favor of addressing
> the strongest ones.
> 
>   o This problem is decreasing in frequency according to vulnerability
>     reports, so there is no urgency about fixing it.
> 
> People aren't going to report vulnerabilities when they are
> persistently told "That's not a bug; that's a feature!"
> Vulnerability reports are self-selected and thus are not a good
> sample for even the most rudimentary statistical analysis like "the
> rate is decreasing."
> 
>   o If you trust user data you are eventually going to get screwed; if
>   not by 'include' then by something else.
> 
> It's not obvious that 'include' can be convinced to execute remote
> code.
> 
>   o We're not fixing it.
> 
> This is simultaneously a weak point and a very strong one.
> Obviously the maintainer of a codebase can publish code with any
> number of vulnerabilities in it and nobody can do anything about it
> other than to stop using the code.  On the other hand, the code is
> still vulnerable, so not fixing it is no solution.
> 
>   o We *are* fixing it, but just not your way.
> 
> Depending on the exact nature of the fix, this may be a reasonable
> response.  The fix needs to address the problem that 'include' has
> hidden sharp edges.  If it merely offers a way to optionally cover the
> sharp edge, then it won't fix the problem.  Other optional fixes
> (e.g. allow_url_fopen==false) haven't yet fixed the problem.  Why
> should this one fix it?
> 
> --
> --My blog is at     blog.russnelson.com         | If you want to find
> Crynwr sells support for free software  | PGPok | injustice in economic
> 521 Pleasant Valley Rd. | +1 315-323-1241       | affairs, look for the
> Potsdam, NY 13676-3213  |                       | hand of a legislator.
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>