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

[Antoine Beaupre]

On Thu Nov 17, 2005 at 11:15:05PM -0800, Steve Langasek wrote:
> On Thu, Nov 17, 2005 at 07:38:18PM -0500, Antoine Beaupre wrote:
> > Package: php4
> > Version: 4:4.3.10-16
> > Followup-For: Bug #336645
> 
> > http://www.hardened-php.net/index.76.html
> 
> > This page explains why the so-called 'globals overwrite' bug matters,
> > even regardless of the register_globals setting. To put it briefly, the
> > $GLOBALS array can be accessed directly by other functions that assume
> > a propar initialization that might have been destroyed by the overwrite.
> 
> > Not sure that is clear enough, read the page above if not.
> 
> 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. 

> 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.

So maybe PEAR needs to be fixed to not use $GLOBALS for hooks (I'd be
curious to see how you do that), or we could simply use my nice little
patch. Or move to 4.4.1.

> So, to my eye, this doesn't seem to be a bug that warrants a stable security
> update; but I've cc:ed the Security Team for comment.  If Debian is actually
> shipping applications which can be exploited in this manner, then doing one
> security update for PHP may be better than doing one for each affected app.

I guess that finding a widely used application that would be vulnerable
would get things moving...

> 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.

Why not just move to 4.4.1 anyways?

A.

[1] http://www.hardened-php.net/advisory_202005.79.html
[2] http://www.hardened-php.net/globals-problem
-------------- 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/52f7abac/attachment.pgp