Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59769
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.216.170 cause and error)
Message-ID: <4F862808.1020405@lerdorf.com>
Date: Wed, 11 Apr 2012 17:55:36 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: John Crenshaw <johncrenshaw@priacta.com>
CC: Stas Malyshev <smalyshev@sugarcrm.com>, 
 Yasuo Ohgaki <yohgaki@ohgaki.net>,
 "internals@lists.php.net" <internals@lists.php.net>
References: <CAGa2bXZ6G=Cphjrde3u1Mq3AAw-4yJk3s28vNe+Aybt2nGTumg@mail.gmail.com> <CAGa2bXZh4uMeUH_BSCFmfNgxS-SZC0svA9BPcSROjwmbfrtFyQ@mail.gmail.com> <CAGa2bXbhi4zdgd9Udo6KsoycDwg_Ke0Xe5h3_-fVDMvn_VfAjQ@mail.gmail.com> <A633CF2D7C7BED41B41F1E64F25507B806A5CDD6C2@MAILR001.mail.lan> <CAGa2bXZKfQ+HqOucwOnBH7gV84hpdxZb5qNY3t3ThF_zMKSGHw@mail.gmail.com> <4F850D06.10701@sugarcrm.com> <CAGa2bXZWrRh8RdMtKK_2_U_XmByC-O6hGRPrJyW5KwvE0CAK-w@mail.gmail.com> <4F8515AF.8060706@sugarcrm.com> <CAGa2bXZWudQeRm5h2eENGmgQDPfOqEmijB9-vPAvfKXLCfDiLw@mail.gmail.com> <4F851FE4.7000706@sugarcrm.com> <CAGa2bXbXdNcfHX_dM2EVVz_2JtS4cc+8pxneSLAd382TuQUg-w@mail.gmail.com> <4F8539E0.1090701@sugarcrm.com> <4F859063.1010401@lerdorf.com> <A633CF2D7C7BED41B41F1E64F25507B806A5CDD71A@MAILR001.mail.lan>
In-Reply-To: <A633CF2D7C7BED41B41F1E64F25507B806A5CDD71A@MAILR001.mail.lan>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options
From: rasmus@lerdorf.com (Rasmus Lerdorf)

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:
>>
>>    Random bytes
>>    <?php kill();?>
>>    More 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 the 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-script injections is a somewhat subtle concept when the real problem is the vulnerable include $_GET['filename'] hole. If this really is a prevalent 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 for 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 vulnerabilities.
> 
> 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 input 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 which each contain encoding information. This would make it possible to concatenate strings just as always, but since the attributes of each block are known the entire string contents could be manipulated to an arbitrary 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 things like XSS and SQL injection it could actually *fix* the otherwise vulnerable 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.  As 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