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. [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
