Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:17018 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 75523 invoked by uid 1010); 29 Jun 2005 22:38:40 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 75503 invoked from network); 29 Jun 2005 22:38:39 -0000 Received: from unknown (HELO pb1.pair.com) (127.0.0.1) by localhost with SMTP; 29 Jun 2005 22:38:39 -0000 X-Host-Fingerprint: 204.11.219.139 lerdorf.com Linux 2.4/2.6 Received: from ([204.11.219.139:38170] helo=colo.lerdorf.com) by pb1.pair.com (ecelerity 1.2 r(5656M)) with SMTP id 58/56-42553-FE223C24 for ; Wed, 29 Jun 2005 18:38:39 -0400 Received: from [192.168.2.106] (c-24-6-1-160.hsd1.ca.comcast.net [24.6.1.160]) (authenticated bits=0) by colo.lerdorf.com (8.13.4/8.13.4/Debian-3) with ESMTP id j5TMcOgS018143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Jun 2005 15:38:25 -0700 Message-ID: <42C322E1.1010608@lerdorf.com> Date: Wed, 29 Jun 2005 15:38:25 -0700 User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russell Nelson CC: internals@lists.php.net References: <42BDDC82.6020208@ohgaki.net> <42C0CF76.6090203@lerdorf.com> <42C0F4DA.4000605@php.net> <17089.18702.450236.614561@desk.crynwr.com> <1119998580.13690.109.camel@localhost> <17089.63833.772427.529013@desk.crynwr.com> <42C1FF2A.4000006@fission.org.uk> <17090.9316.148303.68882@desk.crynwr.com> <30bd802405062822091191c8fc@mail.gmail.com> <17090.15074.92337.224192@desk.crynwr.com> <17091.6714.614244.751950@desk.crynwr.com> In-Reply-To: <17091.6714.614244.751950@desk.crynwr.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] allow_url_fopen should be INI_ALL From: rasmus@lerdorf.com (Rasmus Lerdorf) Russell Nelson wrote: > Nelson Menezes writes: > > The potential for inclusion of malicious code is, if > > anything, a common oversight, not a design flaw. > > If it's a common oversight, then it *is* a design flaw. > > > 1. Create an INI_ALL variable that means something like "allow fopen > > wrappers in include/require" and default it to whatever is thought > > appropriate -- if it *is* a very common oversight, maybe false. > > That would solve the problem. You could still use the sharp edges of > 'include', but you would have to take the sheath off first. > > Does anyone disagree with Nelson's suggestion? If I wrote the patch, > who should I submit it to? It ought to be pretty small, so I could > post it here, but that's probably not right. Yes, most of us disagree. There will be a more complete set of input filtering tools available soon which addresses a broader range of input filtering problems like this one. Simply patching this one isn't going to help much as this particular one is not that common these days. Forget your Google searches and go look at actual vulnerability reports for the last 3 months. -Rasmus