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
signature.asc
Description: Digital signature
