[php-maint] Bug#336645: php4: not only dependent on register_globals

[Steve Langasek]

On Fri, Nov 18, 2005 at 09:47:54AM -0500, Antoine Beaupre wrote:
> > I've read that page; the issue is that I don't see any description of a
> > method of *causing* a $GLOBALS overwrite that doesn't fall into the category
> > of "stupid variable handling". 

> The advisory[1] tells us that PHP 4.3 is currently vulnerable to a
> $GLOBALS overwrite vulnerability in the file upload code. 

*only* when register_globals is turned on.

> > AFAICT, this error only occurs when a PHP
> > application takes arbitrary variable names from an untrusted source, either
> > by register_globals or by manually reimplementing register_globals-like
> > behavior.  I can understand that it's desirable to update PHP so that such
> > stupid variable handling can't be exploited, but it looks to me like the
> > fundamental bug is in the PHP applications that are doing stupid things with
> > variables -- *not* with the PHP engine itself.

> Well, maybe it's not in the PHP engine itself, but PEAR, which is part
> of PHP now, mind you. The globals problem description[2] includes a code
> sample of PEAR.php that is actually vulnerable to a remote execution
> vulnerability, as I understand it.

It's my understanding that this code in PEAR.php is only vulnerable *if* the
code is included in an application which has engaged in Stupid Variable
Handling<tm>.

> So maybe PEAR needs to be fixed to not use $GLOBALS for hooks (I'd be
> curious to see how you do that),

No, it's not a bug to use $GLOBALS.  It's only a bug to allow $GLOBALS to be
overwritten.  This must be done by code external to PEAR.php in order for
this bug to be exploited.

> > Anyway, if you can point me to any evidence that this is exploitable in a
> > default config by means that don't rely on bad PHP coding practices, by all
> > means I would push the Security Team to include an update.  Or if the
> > Security Team themselves feel an update is warranted, I'm more than happy to
> > prepare one at their request regardless.

> Well, I agree with this, but the problem is not necessarly bad coding
> practice. There is a hole, we need to fix it.

That has not actually been demonstrated to my satisfaction.  Given that the
security team has a never-ending supply of exploitable bugs, I'm not keen to
have them spend their time on a bug that is not confirmed to be exploitable
within Debian.

> Why not just move to 4.4.1 anyways?

This is what will be done for unstable, but we don't do this for stable
security updates.  Even if we could generally trust upstreams to not break
things when releasing security-fix updates, we definitely can't trust PHP
upstream to.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon at debian.org                                   http://www.debian.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-php-maint/attachments/20051118/5abff6e5/attachment.pgp