Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:59776 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 67567 invoked from network); 12 Apr 2012 02:10:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Apr 2012 02:10:42 -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.160.170 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.160.170 mail-gy0-f170.google.com Received: from [209.85.160.170] ([209.85.160.170:34579] helo=mail-gy0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CE/0E-23245-0A9368F4 for ; Wed, 11 Apr 2012 22:10:40 -0400 Received: by ghbg2 with SMTP id g2so950107ghb.29 for ; Wed, 11 Apr 2012 19:10:37 -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=Mcq9dV+mmIUwF781+XIIfSUoqM7NETkd2CRswSrJF3U=; b=G9/kFOMkEZRgoY9JJKhBUm3mkLBbFTSfHoKLX4DTc/xMDE1+lNLeUN7RdjAae3Pgw3 eqyaVNTVvXgNcTunD0lozmwc+xMdx8PJ61DDHHUx1eTvIBJDJ1dpBTVfhZRomd8zoVHo YQ3DHrKnJ8Ij9oevJDz4sJDrowsBaxYzHBRPq1X3LqtSEKyzF/Gq2Le4HtQY3pUW+1dh R5yu0C5EC3aYrz+ehpyKISG57ceeVrfIsoBXh9zje2/E0sHq9xhHRRywJzJ2pEqPx+uG 8RrYhrquc0BaEF1mJzLxU2udh/G1vomLbVMqs6YzsRr1gdyaRxnBnIKXwkBY0l5nu6ys Jxhw== Received: by 10.236.161.3 with SMTP id v3mr463049yhk.128.1334196637305; Wed, 11 Apr 2012 19:10:37 -0700 (PDT) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.146.86.14 with HTTP; Wed, 11 Apr 2012 19:09:56 -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> <4F862808.1020405@lerdorf.com> Date: Thu, 12 Apr 2012 11:09:56 +0900 X-Google-Sender-Auth: pNL36Yl-J3i3nMxhavEKgeh48pc Message-ID: To: John LeSueur Cc: Rasmus Lerdorf , John Crenshaw , 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 John LeSueur : > > > On Wed, Apr 11, 2012 at 6:55 PM, Rasmus Lerdorf wrot= e: >> >> On 04/11/2012 10:38 AM, John Crenshaw wrote: >> > From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com] >> >> I guess he is saying that it prevents: >> >> >> >> =A0 =A0Random bytes >> >> =A0 =A0 >> >> =A0 =A0More random bytes >> >> >> >> Where random bytes might be an image file so finfo_file() might >> >> identify it as a valid image >> > >> > Right, but anyone can trivially construct a fully valid bitmap with a >> > starting byte sequence of `42 4D 3B 2F 2A`, which resolves to `BM;/*`.= PHP >> > will decide that BM meant 'BM', effectively skipping it, then the open >> > comment will slide the PHP interpreter past any remaining header stuff= . You >> > can close the comment and place the actual code payload anywhere in th= e >> > image data. The early bytes in other image formats are similarly >> > exploitable. As far as I can tell there is really no security win here= . >> > >> >> 4. Only protecting against mid-script injections and not top-of-scrip= t >> >> injections is a somewhat subtle concept when the real problem is the >> >> vulnerable include $_GET['filename'] hole. If this really is a preval= ent >> >> problem, maybe instead of trying to mitigate the symptoms, why don't = we try >> >> to attack the actual cause of the problem. I would love to hear some = ideas >> >> along those lines that don't fundamentally change the nature of PHP f= or >> >> somewhat cloudy benefits. >> >> >> >> -Rasmus >> > >> > It's disturbingly common. Probably 90% of the automated attacks I see = in >> > the 404 error logs are trying to exploit various inclusion vulnerabili= ties. >> > >> > One idea that comes to mind immediately is the old taint RFC: >> > https://wiki.php.net/rfc/taint. This doesn't actually prevent LFI, but= it >> > (optionally) warns the developer that they did something very bad, >> > regardless of whether it actually caused a problem with the specific i= nput >> > data. I'd really love to see that one finalized and implemented. >> > >> > Another wild alternative could be to have a non-trivial string format >> > internally, where PHP strings are actually a set of distinct blocks wh= ich >> > each contain encoding information. This would make it possible to >> > concatenate strings just as always, but since the attributes of each b= lock >> > are known the entire string contents could be manipulated to an arbitr= ary >> > final encoding, (or rejected as impossible to safely convert) when the >> > string is actually used. In the include case this isn't really very >> > different from taint, because safe conversion is impossible, but for t= hings >> > like XSS and SQL injection it could actually *fix* the otherwise vulne= rable >> > code. A simplified example of how this might work: >> >> I think you may be overthinking it. I was thinking more along the lines >> of having some rules for include/require. Something like every >> non-relative include/require must start with a const string and any >> variable part cannot have '..' in it. =A0As in: >> >> Say $variable gets set to '/etc/passwd' then >> >> include $variable; >> >> would fail because it is an absolute-path include without a leading >> const. However, this would work: >> >> include '/tmp/' . $variable; >> >> And so would this: >> >> include INSTALL_PATH . $variable; >> >> Relative includes including the ones that are relative to include_path >> wouldn't change. If the bad guys can write to the doc root or a >> directory below the doc root then they don't need LFI, they can just hit >> the path directly from their browser. >> >> Obviously still disruptive and there would be some BC breaks, but I bet >> it would be more effective than trying to optionally turn off the parser >> in the right places. >> >> -Rasmus >> > > If this were in serious consideration, wouldn't it need to be two > parameters, so that the engine can check them separately? > > If we really are concerned about developers creating LFI vulnerabilities[= 1], > I think this is the way to do it. It's a little like setting open_basedir > before every include, but requiring the open_basedir to be a constant. > Developers can deliberately sidestep this if they need to use a variable, > like: > > define('install_dir', $config['install_dir']); > include myPath, $file; > > As you said, there's still a lot of disruption, so it's only worth it if = we > really think that preventing developers from writing vulnerable code is > required, because education won't work. That's true. Education won't work. > > Overall, I'm ambivalent about allowing some files to omit disallowing ?> in those files. If we do so, it feels more like the file > itself should somehow communicate that it should be parsed differently[2]= , > rather than making it the responsibility of the including script. Any > security benefit is more like a side effect than the motivating factor. > Relying on php's failure to parse a file isn't security, it's an accident= . > Right. Other languages are relying on an accident when things goes wrong. This situation should not happen in first place, but what the important is system will be protected instead of serious disaster. This difference is the last PHP security issue that other language users point out as PHP is poor on security. This is what I would like to change if PHP is going to support script only files. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net > Thanks, > John > > [1] there really are a lot out there, and from the little I saw, it's > usually in CMS's which are often used by non-php programmers, and the > plugins are often written as a first-time, let's try this out kind of thi= ng. > [2] starting with " people's objection to using conventions with a flag to the include construct seem like an acceptable > second choice though. >