Everything

php

PHP 5.2.0 release with "broken" input filters

php.internals

Stefan Esser

19 years ago

Hi,

I just wanted to remind you that PHP 5.2.0 will be released with broken
and inconsistent input filtering.

Right now _SERVER is only passed through the input filter for apache 1
SAPI. All other SAPIs do not pass _SERVER variables through the filter.
This will be a major headache for people using ext/filter etc...

Stefan

Pierre Joye

19 years ago

Hello Stefan,

On 10/23/06, Stefan Esser <sesser@hardened-php.net> wrote:

> Hi,
>
> I just wanted to remind you that PHP 5.2.0 will be released with broken
> and inconsistent input filtering.
>
> Right now _SERVER is only passed through the input filter for apache 1
> SAPI. All other SAPIs do not pass _SERVER variables through the filter.

While discussing a couple bugs related to SERVER and ENV with Ilia
(empty value, leaks and JIT problems in other SAPI or CLI), we
decided to disable them if no soloution has been found for these two
inputs. They are still present for now, during the RC phase.

The problem is to keep JIT working even when a default filter is
defined, it makes little sense to initialize and duplicate these
variable during the sapi filtering step.

> This will be a major headache for people using ext/filter etc...

etc...?

--Pierre

Ilia A.

19 years ago

On 23-Oct-06, at 4:48 AM, Stefan Esser wrote:

> Hi,
>
> I just wanted to remind you that PHP 5.2.0 will be released with
> broken
> and inconsistent input filtering.
>
> Right now _SERVER is only passed through the input filter for apache 1
> SAPI. All other SAPIs do not pass _SERVER variables through the
> filter.
> This will be a major headache for people using ext/filter etc...

In some SAPIs such as CLI it makes little sense to filter $_SERVER in
majority of cases. As a whole I do not believe $_SERVER in its
entirety needs to be filtered, given that at least 1/2 the data there
is not based on user-input. My suggestion is that people use
filter_var() function to filter components of the $_SERVER super-
global that they are using.

That said, in future release there are plans to extend support to
Apache 2 and cgi/fcgi sapis as well as add handling for $_REQUEST.


Ilia Alshanetsky

Pierre Joye

19 years ago

Hello,

On 10/23/06, Ilia Alshanetsky <ilia@prohost.org> wrote:

>
> On 23-Oct-06, at 4:48 AM, Stefan Esser wrote:
>
> > Hi,
> >
> > I just wanted to remind you that PHP 5.2.0 will be released with
> > broken
> > and inconsistent input filtering.
> >
> > Right now _SERVER is only passed through the input filter for apache 1
> > SAPI. All other SAPIs do not pass _SERVER variables through the
> > filter.
> > This will be a major headache for people using ext/filter etc...
>
> In some SAPIs such as CLI it makes little sense to filter $_SERVER in
> majority of cases. As a whole I do not believe $_SERVER in its
> entirety needs to be filtered, given that at least 1/2 the data there
> is not based on user-input. My suggestion is that people use
> filter_var() function to filter components of the $_SERVER super-
> global that they are using.
>
> That said, in future release there are plans to extend support to
> Apache 2 and cgi/fcgi sapis as well as add handling for $_REQUEST.

Yes, and more generally as soon as we fix the leaks and the other
troubles we spoted recently. I still like to disable ENV/SERVER
support in 5.2.0 (just like _REQUEST), we can restore it later.

--Pierre

Pierre Joye

19 years ago

Hello,

On 10/23/06, Pierre <pierre.php@gmail.com> wrote:

> Hello,
>
> On 10/23/06, Ilia Alshanetsky <ilia@prohost.org> wrote:
> >
> > On 23-Oct-06, at 4:48 AM, Stefan Esser wrote:
> >
> > > Hi,
> > >
> > > I just wanted to remind you that PHP 5.2.0 will be released with
> > > broken
> > > and inconsistent input filtering.
> > >
> > > Right now _SERVER is only passed through the input filter for apache 1
> > > SAPI. All other SAPIs do not pass _SERVER variables through the
> > > filter.
> > > This will be a major headache for people using ext/filter etc...
> >
> > In some SAPIs such as CLI it makes little sense to filter $_SERVER in
> > majority of cases. As a whole I do not believe $_SERVER in its
> > entirety needs to be filtered, given that at least 1/2 the data there
> > is not based on user-input. My suggestion is that people use
> > filter_var() function to filter components of the $_SERVER super-
> > global that they are using.
> >
> > That said, in future release there are plans to extend support to
> > Apache 2 and cgi/fcgi sapis as well as add handling for $_REQUEST.
>
> Yes, and more generally as soon as we fix the leaks and the other
> troubles we spoted recently. I still like to disable ENV/SERVER
> support in 5.2.0 (just like _REQUEST), we can restore it later.

I just discussed with Ilia about this problem. 5.2.0 will be kept as
it is now, only the apache1 sapi will be supported. Other sapi will be
introduced for 5.2.1.

Ilia already have a patch for apache2 sapi support, it will be
commited in HEAD as soon as possible, other will follow.

Thanks for the head up,

--Pierre

Rasmus Lerdorf

19 years ago

Ilia Alshanetsky wrote:

>
> On 23-Oct-06, at 4:48 AM, Stefan Esser wrote:
>
>> Hi,
>>
>> I just wanted to remind you that PHP 5.2.0 will be released with broken
>> and inconsistent input filtering.
>>
>> Right now _SERVER is only passed through the input filter for apache 1
>> SAPI. All other SAPIs do not pass _SERVER variables through the filter.
>> This will be a major headache for people using ext/filter etc...
>
> In some SAPIs such as CLI it makes little sense to filter $_SERVER in
> majority of cases. As a whole I do not believe $_SERVER in its entirety
> needs to be filtered, given that at least 1/2 the data there is not
> based on user-input. My suggestion is that people use filter_var()
> function to filter components of the $_SERVER super-global that they are
> using.

I had left out SERVER filtering in the initial version for much the same
reasoning, but it turns out that a good chunk of holes were due to the
fact that people used $_SERVER['REQUEST_URI'] unfiltered.  Trying to
teach people which SERVER vars are safe and which aren't isn't a fun
task and the whole point of the filter extension is to take away the
guessing game.

-Rasmus

Richard Lynch

19 years ago

On Mon, October 23, 2006 12:38 pm, Rasmus Lerdorf wrote:

> I had left out SERVER filtering in the initial version for much the
> same
> reasoning, but it turns out that a good chunk of holes were due to the
> fact that people used $_SERVER['REQUEST_URI'] unfiltered.  Trying to
> teach people which SERVER vars are safe and which aren't isn't a fun
> task and the whole point of the filter extension is to take away the
> guessing game.

Perhaps in 6.0 one could consider having:

$_SERVER
$_SERVER_DIRTY

or some similar scheme so that people *know* there is something
"wrong" with just blindly using that data...

Or rename it, so it's not "SERVER" for user-supplied data...

I mean, you've labeled it "SERVER" so I figure it comes from the
SERVER, right?  Not from the USER...  I know, that's a stupid way to
look at things, but there it is.

PS Digging the Yahoo! Maps API :-)

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

Peter Brodersen

19 years ago

On Mon, 23 Oct 2006 10:38:31 -0700, in php.internals
rasmus@lerdorf.com (Rasmus Lerdorf) wrote:

>I had left out SERVER filtering in the initial version for much the same
>reasoning, but it turns out that a good chunk of holes were due to the
>fact that people used $_SERVER['REQUEST_URI'] unfiltered.  Trying to
>teach people which SERVER vars are safe and which aren't isn't a fun
>task and the whole point of the filter extension is to take away the
>guessing game.

More well-known, the same goes for the HTTP headers populated in
_SERVER as well, even though some might be less obvious than other.

HTTP_HOST could be tainted as well in some cases where a DNS entry and
ServerAlias of *.example.com exists.

An attacker could trick a user into visiting
www.%22%3EXSS.example.com which at least IE6 would accept as a valid
URL.

--
- Peter Brodersen

Rasmus Lerdorf

19 years ago

Peter Brodersen wrote:

> On Mon, 23 Oct 2006 10:38:31 -0700, in php.internals
> rasmus@lerdorf.com (Rasmus Lerdorf) wrote:
>
>> I had left out SERVER filtering in the initial version for much the same
>> reasoning, but it turns out that a good chunk of holes were due to the
>> fact that people used $_SERVER['REQUEST_URI'] unfiltered.  Trying to
>> teach people which SERVER vars are safe and which aren't isn't a fun
>> task and the whole point of the filter extension is to take away the
>> guessing game.
>
> More well-known, the same goes for the HTTP headers populated in
> _SERVER as well, even though some might be less obvious than other.
>
> HTTP_HOST could be tainted as well in some cases where a DNS entry and
> ServerAlias of *.example.com exists.

Actually, by using the Flash hack, you don't need wildcard DNS to
exploit that one.  As anybody who has seen my ranting lately can attest
to, name-based virtual hosting is completely broken until we get
everyone onto Flash9.

-Rasmus

Richard Lynch

19 years ago

On Mon, October 23, 2006 6:26 pm, Rasmus Lerdorf wrote:

> Peter Brodersen wrote:
>> On Mon, 23 Oct 2006 10:38:31 -0700, in php.internals
>> rasmus@lerdorf.com (Rasmus Lerdorf) wrote:
>>
>>> I had left out SERVER filtering in the initial version for much the
>>> same
>>> reasoning, but it turns out that a good chunk of holes were due to
>>> the
>>> fact that people used $_SERVER['REQUEST_URI'] unfiltered.  Trying
>>> to
>>> teach people which SERVER vars are safe and which aren't isn't a
>>> fun
>>> task and the whole point of the filter extension is to take away
>>> the
>>> guessing game.
>>
>> More well-known, the same goes for the HTTP headers populated in
>> _SERVER as well, even though some might be less obvious than other.
>>
>> HTTP_HOST could be tainted as well in some cases where a DNS entry
>> and
>> ServerAlias of *.example.com exists.
>
> Actually, by using the Flash hack, you don't need wildcard DNS to
> exploit that one.  As anybody who has seen my ranting lately can
> attest
> to, name-based virtual hosting is completely broken until we get
> everyone onto Flash9.

Haven't read the rant (yet) but, errrr, have they released Flash
anything in this millenium for Linux?...

Cuz it seems like I never can manage to get to download anything
higher than Flash Player 6 for my Linux box desktop at home. Which is
ancient hardware/OS, so maybe that's the issue...

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

Pierre Joye

19 years ago

Hello,

On 10/26/06, Richard Lynch <ceo@l-i-e.com> wrote:

> Haven't read the rant (yet) but, errrr, have they released Flash
> anything in this millenium for Linux?...
>
> Cuz it seems like I never can manage to get to download anything
> higher than Flash Player 6 for my Linux box desktop at home. Which is
> ancient hardware/OS, so maybe that's the issue...

Besides the fact that it is off topic, yes, they've released flash for
linux. The flash 9 beta has been released a couple of weeks ago.

--Pierre