Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:59755
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.170 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: Thu, 12 Apr 2012 00:09:48 +0300
Message-ID: <CAL0xaBHiyR2aQ1rcJo3dn=+Dj=nbOjKOdOJSSeMT1MTno9MH-g@mail.gmail.com>
To: John Crenshaw <johncrenshaw@priacta.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>, Yasuo Ohgaki <yohgaki@ohgaki.net>, 
	Stas Malyshev <smalyshev@sugarcrm.com>, Rasmus Lerdorf <rasmus@lerdorf.com>
Content-Type: multipart/alternative; boundary=14dae9340b75df762a04bd6da875
Subject: RE: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--14dae9340b75df762a04bd6da875
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Taints actually got implemented and released as a PECL package. I allready
use them on our dev server and they really help to find and fix issues with
data escaping all over the place, even though we pay a lot of attention to
this stuff. The only sad thing is that there is no noise at the moment
about it.
11.04.2012 19:40 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=
=B5=D0=BB=D1=8C "John Crenshaw" <johncrenshaw@priacta.com>
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:

> 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 identif=
y
> 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;/*`. PH=
P
> will decide that BM meant 'BM', effectively skipping it, then the open
> comment will slide the PHP interpreter past any remaining header stuff. Y=
ou
> 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 t=
ry
> to attack the actual cause of the problem. I would love to hear some idea=
s
> 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 vulnerabilitie=
s.
>
> 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 inpu=
t
> 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 bloc=
k
> 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 thin=
gs
> like XSS and SQL injection it could actually *fix* the otherwise vulnerab=
le
> code. A simplified example of how this might work:
>
> http://example.com?name=3D%3Cscript%3Exss()%3B%3C%2Fscript%3E
>
> // $_GET['name'] =3D=3D=3D [text&user&utf8('<script>xss();</script>')];
> $name =3D $_GET['name'];
>
> $welcome =3D html("Welcome <b>$name</b>!"); // $welcome =3D=3D=3D [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, ther=
e
> is some BC break (especially where an input was known to be HTML but
> secured via something like HTMLPurifier), and there are huge open questio=
ns
> (like how to handle string comparison). Still, I think it is interesting
> because it actually divines the real meaning. The intent of the above cod=
e
> 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
>
>

--14dae9340b75df762a04bd6da875--