Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:17030 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 9123 invoked by uid 1010); 30 Jun 2005 05:18:40 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 9108 invoked from network); 30 Jun 2005 05:18:40 -0000 Received: from unknown (HELO crynwr.com) (127.0.0.1) by localhost with SMTP; 30 Jun 2005 05:18:40 -0000 X-Host-Fingerprint: 192.203.178.14 ns1.crynwr.com Linux 2.0.3x (1) Received: from ([192.203.178.14:1055] helo=ns1.crynwr.com) by pb1.pair.com (ecelerity 1.2 r(5656M)) with SMTP id 70/FF-42553-FA083C24 for ; Thu, 30 Jun 2005 01:18:40 -0400 Received: (qmail 8835 invoked from network); 30 Jun 2005 05:16:07 -0000 Received: from dpc6745223014.direcpc.com (HELO desk.crynwr.com) (67.45.223.14) by pdam.crynwr.com with SMTP; 30 Jun 2005 05:16:07 -0000 Received: (qmail 20732 invoked by uid 500); 30 Jun 2005 05:15:30 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dog; d=crynwr.com; b=MHR5IgsvPydCM2esxuSlYWZo7ebCURfqBYyW0hGgJ9krMzft3cjNA7bmj50mLKk1 ; MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17091.32753.839430.671829@desk.crynwr.com> Date: Thu, 30 Jun 2005 01:15:29 -0400 To: internals@lists.php.net X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid Subject: Bringing the 'include' discussion to an end From: nelson@crynwr.com (Russell Nelson) 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.