PHP 4.4.1 fixes security bugs

Debian Bug report logs - #336645
PHP 4.4.1 fixes security bugs

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Florian Weimer <fw@deneb.enyo.de>

To: submit@bugs.debian.org

Subject: PHP 4.4.1 fixes security bugs

Date: Mon, 31 Oct 2005 19:14:55 +0100

Package: php4
Tags: security
Severity: grave

The Hardened-PHP project has disclosed several security
vulnerabilites:

  <http://www.hardened-php.net/advisory_182005.77.html>
  <http://www.hardened-php.net/advisory_192005.78.html>
  <http://www.hardened-php.net/advisory_202005.79.html>
  <http://www.hardened-php.net/globals-problem>

The "globals problem" appears to be somewhat nasty.  It is not clear
if it applies to stable's 4.3.10 version because the security feature
which turned out to be buggy was introduced in 4.3.11, according to
the fourth link above.  (Maybe PHP before 4.3.11 is vulnerable to some
other issue; I don't know.)

As usual, the 4.4.1 release might fix additional security bugs for
which no explicit advisories are released.

Message #10 received at 336645@bugs.debian.org (full text, mbox, reply):

From: Florian Weimer <fw@deneb.enyo.de>

To: 336645@bugs.debian.org

Subject: Re: Bug#336645: PHP 4.4.1 fixes security bugs

Date: Mon, 31 Oct 2005 20:54:39 +0100

* Florian Weimer:

>   <http://www.hardened-php.net/advisory_182005.77.html>

This appears to be a variant of CVE-2002-1954, although public
information is scarce at this stage.  See the discussion on
full-disclosure and various other places.

Message #15 received at 336645@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Florian Weimer <fw@deneb.enyo.de>, 336645@bugs.debian.org

Subject: Re: Bug#336645: PHP 4.4.1 fixes security bugs

Date: Mon, 31 Oct 2005 23:31:47 -0800

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Oct 31, 2005 at 07:14:55PM +0100, Florian Weimer wrote:
> Package: php4
> Tags: security
> Severity: grave

> The Hardened-PHP project has disclosed several security
> vulnerabilites:

>   <http://www.hardened-php.net/advisory_182005.77.html>
>   <http://www.hardened-php.net/advisory_192005.78.html>
>   <http://www.hardened-php.net/advisory_202005.79.html>
>   <http://www.hardened-php.net/globals-problem>

> The "globals problem" appears to be somewhat nasty.  It is not clear
> if it applies to stable's 4.3.10 version because the security feature
> which turned out to be buggy was introduced in 4.3.11, according to
> the fourth link above.  (Maybe PHP before 4.3.11 is vulnerable to some
> other issue; I don't know.)

The globals problem described does apply to php 4.3.10.

However, in reading over the description of the vulnerabilities, I don't
really see any grounds for regarding these as grave securty bugs.  The most
severe of these problems, 202005.79, only has a significant impact when
register_globals is set in the PHP environment -- a setting which has been
strongly deprecated for quite some time, and which is disabled by default in
sarge.  There is a *lot* of PHP application code that is vulnerable to XSS
or remote injection attacks when run with register_globals on, or which does
stupid things with manually registering request variables as global
variables; I'm not convinced that this warrants a grave bug against PHP...

- -- 
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@debian.org                                   http://www.debian.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDZxnjKN6ufymYLloRAlbzAJ9WEN3VAYDovKNzoW5RyTHxuMy38QCgv49I
CrTe7FA6zS0K22ZHRjk+P24=
=8OyH
-----END PGP SIGNATURE-----

Message #20 received at 336645@bugs.debian.org (full text, mbox, reply):

From: Florian Weimer <fw@deneb.enyo.de>

To: Steve Langasek <vorlon@debian.org>

Cc: 336645@bugs.debian.org

Subject: Re: Bug#336645: PHP 4.4.1 fixes security bugs

Date: Tue, 01 Nov 2005 08:54:08 +0100

* Steve Langasek:

> However, in reading over the description of the vulnerabilities, I don't
> really see any grounds for regarding these as grave securty bugs.  The most
> severe of these problems, 202005.79, only has a significant impact when
> register_globals is set in the PHP environment -- a setting which has been
> strongly deprecated for quite some time, and which is disabled by default in
> sarge.  There is a *lot* of PHP application code that is vulnerable to XSS
> or remote injection attacks when run with register_globals on,

There are plenty installations in the field which run with
register_globals=on.  If I read the report correctly, some common
workarounds to port code to register_globals=off also result in
vulnerabilities.  While the compatibility code should probably be
considered vulnerable, it's desirable security-wise to add some
additional protection.  However, after taking other factors into
account, it might still be a poor trade-off, of course.

> or which does stupid things with manually registering request
> variables as global variables; I'm not convinced that this warrants
> a grave bug against PHP...

I think it's boils down to whether Debian wants to offer security
support for register_globals=on configurations.  So far, I assumed the
answer is "yes".  I don't mind changing it to a "no" for practical
reasons, but this has to be documented somewhere (like the lack of
"safe mode" security support, ahem).

Message #25 received at 336645@bugs.debian.org (full text, mbox, reply):

From: Moritz Muehlenhoff <jmm@inutil.org>

To: 336645@bugs.debian.org

Subject: More vulnerabilities

Date: Tue, 1 Nov 2005 10:50:42 +0100

Just for the record, PHP 4.4.1 fixes more security problems
besides the ones discovered by the Hardened PHP Project.
I'm including the CVE assignments:

* Fixed multiple safe_mode/open_basedir bypass vulnerabilities 
  in ext/curl and ext/gd that could lead to exposure of
  files normally not accessible due to safe_mode or open_basedir
  restrictions. (CVE-2005-3391)
* Fixed an issue with trailing slashes in allowed basedirs. They
  were ignored by open_basedir checks, so that specified
  basedirs were handled as prefixes and not as full directory
  names. (there doesn't seem to be a CVE assignment yet)
* Fixed an issue with calling [19]virtual() on Apache 2. This
  allowed bypassing of certain configuration directives like
  safe_mode or open_basedir. (CVE-2005-3392)

Cheers,
        Moritz

Message #30 received at 336645@bugs.debian.org (full text, mbox, reply):

From: Adam Conrad <adconrad@0c3.net>

To: Moritz Muehlenhoff <jmm@inutil.org>, 336645@bugs.debian.org

Subject: Re: [php-maint] Bug#336645: More vulnerabilities

Date: Tue, 01 Nov 2005 11:01:10 -0500

Moritz Muehlenhoff wrote:
> 
> * Fixed an issue with trailing slashes in allowed basedirs. They
>   were ignored by open_basedir checks, so that specified
>   basedirs were handled as prefixes and not as full directory
>   names. (there doesn't seem to be a CVE assignment yet)

This was assigned CAN-2005-3054, the patch was submitted upstream by me,
and it's been fixed in Sid.  The fix is committed to the sarge branch in
SVN, but as we don't tend to consider open_basedir/safe_mode bypasses as
critical security bugs, I'm rolling up all the current bugfixes and will
be preparing an upload for all of them at once.

... Adam

Message #35 received at 336645@bugs.debian.org (full text, mbox, reply):

From: "Tomas Kuliavas" <tokul@users.sourceforge.net>

To: 336645@bugs.debian.org

Subject: php 4.4.1 is broken

Date: Fri, 4 Nov 2005 14:14:18 +0200 (EET)

Please make sure that you solved http://bugs.php.net/bug.php?id=35067
before adding php 4.4.1 package to debian sid.

-- 
Tomas

Message #40 received at 336645@bugs.debian.org (full text, mbox, reply):

From: Christian Stadler <stadler@ragnarokonline.de>

To: 336645@bugs.debian.org

Subject: Re: Bug#336645: php 4.4.1 is broken

Date: Sat, 05 Nov 2005 07:45:14 +0100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tomas Kuliavas wrote:
> Please make sure that you solved http://bugs.php.net/bug.php?id=35067
> before adding php 4.4.1 package to debian sid.

PHP 4.4.2 will be released soon. See http://news.php.net/php.internals/19898

Perhaps its better to wait, until PHP 4.4.2 has been released?

Regards,
  Christian Stadler
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDbFT29250Hcbf/3IRAiU7AJ9GjBefEzJ80lLJpLNh75MiXxEN/gCbBL2B
3mO1z3U1YKC2ofDeGYA+Zg0=
=Acb/
-----END PGP SIGNATURE-----

Message #45 received at 336645@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupre <anarcat@koumbit.net>

To: Debian Bug Tracking System <336645@bugs.debian.org>

Subject: php4: not only dependent on register_globals

Date: Thu, 17 Nov 2005 19:38:18 -0500

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.

My point is: this has close to nothing to do with register_globals.
There's a serious security issue, it needs to be fixed. Any pointers on
the actual patch applied in 4.4.1?

Thanks,

A.

Message #50 received at 336645@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupre <anarcat@koumbit.net>

To: Debian Bug Tracking System <336645@bugs.debian.org>

Subject: php4: here is the patch

Date: Thu, 17 Nov 2005 20:04:30 -0500

Package: php4
Version: 4:4.3.10-16
Followup-For: Bug #336645


here is a patch that applies cleanly on sarge:

http://cvs.php.net/diff.php/php-src/ext/standard/basic_functions.c?r1=1.543.2.51.2.2&r2=1.543.2.51.2.3&ty=h

I append a modified patch that will apply cleanly on the sarge tree. I
hope this is going to help getting this fixed.

===================================================================
RCS file: /repository/php-src/ext/standard/basic_functions.c,v
retrieving revision 1.543.2.51.2.2
retrieving revision 1.543.2.51.2.3
diff -p --unified=3 -r1.543.2.51.2.2 -r1.543.2.51.2.3
--- basic_functions.c	2005/09/13 13:23:56	1.543.2.51.2.2
+++ basic_functions.c	2005/09/29 16:31:48	1.543.2.51.2.3
@@ -3027,11 +3027,25 @@
 	prefix = va_arg(args, char *);
 	prefix_len = va_arg(args, uint);

-	new_key_len = prefix_len + hash_key->nKeyLength;
-	new_key = (char *) emalloc(new_key_len);
+	if (!prefix_len) {
+		if (!hash_key->nKeyLength) {
+			php_error_docref(NULL TSRMLS_CC, E_WARNING, "Numeric key detected - possible security hazard.");
+			return 0;
+		} else if (!strcmp(hash_key->arKey, "GLOBALS")) {
+			php_error_docref(NULL TSRMLS_CC, E_WARNING, "Attempted GLOBALS variable overwrite.");
+			return 0;
+		}
+	}
+
+	if (hash_key->nKeyLength) {
+		new_key_len = prefix_len + hash_key->nKeyLength;
+		new_key = (char *) emalloc(new_key_len);

-	memcpy(new_key, prefix, prefix_len);
-	memcpy(new_key+prefix_len, hash_key->arKey, hash_key->nKeyLength);
+		memcpy(new_key, prefix, prefix_len);
+		memcpy(new_key+prefix_len, hash_key->arKey, hash_key->nKeyLength);
+	} else {
+		new_key_len = spprintf(&new_key, 0, "%s%ld", prefix, hash_key->h);
+	}

 	zend_hash_del(&EG(symbol_table), new_key, new_key_len);
 	ZEND_SET_SYMBOL_WITH_LENGTH(&EG(symbol_table), new_key, new_key_len, *var, (*var)->refcount+1, 0);

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.31
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages php4 depends on:
ii  libapache-mod-php4           4:4.3.10-16 server-side, HTML-embedded scripti
ii  php4-common                  4:4.3.10-16 Common files for packages built fr

-- debconf information excluded

Message #55 received at 336645@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Antoine Beaupre <anarcat@koumbit.net>, 336645@bugs.debian.org

Cc: team@security.debian.org

Subject: Re: Bug#336645: php4: not only dependent on register_globals

Date: Thu, 17 Nov 2005 23:15:05 -0800

[Message part 1 (text/plain, inline)]

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

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.

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.

-- 
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@debian.org                                   http://www.debian.org/

[signature.asc (application/pgp-signature, inline)]

Message #60 received at 336645@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupre <anarcat@koumbit.net>

To: Steve Langasek <vorlon@debian.org>

Cc: 336645@bugs.debian.org, team@security.debian.org

Subject: Re: Bug#336645: php4: not only dependent on register_globals

Date: Fri, 18 Nov 2005 09:47:54 -0500

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, inline)]

Message #65 received at 336645@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Antoine Beaupre <anarcat@koumbit.net>, 336645@bugs.debian.org

Cc: team@security.debian.org

Subject: Re: Bug#336645: php4: not only dependent on register_globals

Date: Fri, 18 Nov 2005 09:44:47 -0800

[Message part 1 (text/plain, inline)]

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@debian.org                                   http://www.debian.org/

[signature.asc (application/pgp-signature, inline)]

Message #70 received at 336645@bugs.debian.org (full text, mbox, reply):

From: David Mitchell <mitchell@ucar.edu>

To: 336645@bugs.debian.org

Cc: David Mitchell <mitchell@ucar.edu>

Subject: Bug 336645: PHP 4.4.1 Security Fixes

Date: Fri, 02 Dec 2005 10:20:48 -0700

As a user, I wanted to throw my two cents in. Our security administrator 
_is_ considering this particular fix to be critical, and has made it a 
required patch. While it's true that this particular fix is protecting 
against poorly written PHP scripts, it also appears to be the case that 
such poorly written software is fairly common and is being actively 
targeted. I also think that with this patch in PHP itself, there will be 
a lot less pressure for any of the packages which employ unsafe variable 
handling to actually get fixed. I know that I personally don't have a 
lot of say on the matter, but it would be nice if the patched version 
was released sooner. Thanks for your time.

-David Mitchell


-- 
-----------------------------------------------------------------
| David Mitchell (mitchell@ucar.edu)       Network Engineer IV  |
| Tel: (303) 497-1845                      National Center for  |
| FAX: (303) 497-1818                      Atmospheric Research |
-----------------------------------------------------------------

Message #75 received at 336645@bugs.debian.org (full text, mbox, reply):

From: Christian Stadler <stadler@ragnarokonline.de>

To: David Mitchell <mitchell@ucar.edu>, 336645@bugs.debian.org

Subject: Re: Bug#336645: Bug 336645: PHP 4.4.1 Security Fixes

Date: Fri, 02 Dec 2005 18:40:20 +0100

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Mitchell wrote:
> As a user, I wanted to throw my two cents in. Our security administrator
> _is_ considering this particular fix to be critical, and has made it a
> required patch. While it's true that this particular fix is protecting
> against poorly written PHP scripts, it also appears to be the case that
> such poorly written software is fairly common and is being actively
> targeted. I also think that with this patch in PHP itself, there will be
> a lot less pressure for any of the packages which employ unsafe variable
> handling to actually get fixed. I know that I personally don't have a
> lot of say on the matter, but it would be nice if the patched version
> was released sooner. Thanks for your time.

You can always turn off register_globals in you php.ini.
register_globals = Off is a recommended setting anyway.

Regards,
  Christian Stadler
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFDkIcC9250Hcbf/3IRArrOAJwMks6Iifcri/wNEkgEsGmt5jt4dwCcDqm2
epwlnPWFlDF6MiTfeTd1SFM=
=nGgv
-----END PGP SIGNATURE-----

Message #80 received at 336645@bugs.debian.org (full text, mbox, reply):

From: David Mitchell <mitchell@ucar.edu>

To: Christian Stadler <stadler@ragnarokonline.de>

Cc: 336645@bugs.debian.org, David Mitchell <mitchell@ucar.edu>

Subject: Re: Bug#336645: Bug 336645: PHP 4.4.1 Security Fixes

Date: Fri, 02 Dec 2005 11:18:39 -0700

Christian Stadler wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> David Mitchell wrote:
> 
>>As a user, I wanted to throw my two cents in. Our security administrator
>>_is_ considering this particular fix to be critical, and has made it a
>>required patch. While it's true that this particular fix is protecting
>>against poorly written PHP scripts, it also appears to be the case that
>>such poorly written software is fairly common and is being actively
>>targeted. I also think that with this patch in PHP itself, there will be
>>a lot less pressure for any of the packages which employ unsafe variable
>>handling to actually get fixed. I know that I personally don't have a
>>lot of say on the matter, but it would be nice if the patched version
>>was released sooner. Thanks for your time.
> 
> 
> You can always turn off register_globals in you php.ini.
> register_globals = Off is a recommended setting anyway.

I do have it off. But there is code which basically re-implements 
register_globals. The patch actually checks to ensure that you don't try 
to re-define the global variable named "GLOBAL". I'm not worried about 
my own code, since I do my best to practice safe variable handling. 
Apparently some authors took a short cut and have re-implemented 
register_globals using code like this:

foreach ($_REQUEST as $key => $value) $$key = $value;

Is that a dangerous thing to do? Sure. But that doesn't mean it's not 
being done. As I said, it seems to be common enough that the patch to 
prevent it being dangerous has gone from being in Hardened-PHP to 
mainline PHP to having a CVE to being a mandatory patch in my 
organization. That's a lot of people who seem to think it's a serious 
issue. And as I said, if the upstream PHP is patched to prevent the 
above code from being dangerous then there is no incentive for anybody 
to fix the scripts which do have unsafe variable handling code in them.

I think an argument can be made that Sarge needs to either have the 
patch in question applied or it needs to have all the PHP-dependent 
packages checked to make sure they aren't doing unsafe things with 
request variables. The latter is not realistically going to happen 
because the PHP developers seem to have decided that the former is the 
proper fix.

Personally, I don't have a big stake in the final outcome of this. I 
don't have much PHP code on my systems, and what I do have is in-house 
stuff which was written with safe variable handling in mind. That said, 
I don't want to have to go to my security administrator and explain why 
my distro of choice needs to have an exception to our patching policy 
made for it.

-David Mitchell

> 
> Regards,
>   Christian Stadler
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.0 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFDkIcC9250Hcbf/3IRArrOAJwMks6Iifcri/wNEkgEsGmt5jt4dwCcDqm2
> epwlnPWFlDF6MiTfeTd1SFM=
> =nGgv
> -----END PGP SIGNATURE-----


-- 
-----------------------------------------------------------------
| David Mitchell (mitchell@ucar.edu)       Network Engineer IV  |
| Tel: (303) 497-1845                      National Center for  |
| FAX: (303) 497-1818                      Atmospheric Research |
-----------------------------------------------------------------

Message #85 received at 336645@bugs.debian.org (full text, mbox, reply):

From: Anthony DeRobertis <anthony@derobert.net>

To: 336645@bugs.debian.org

Subject: Please fix this, even if it doesn't affect the default config

Date: Sun, 01 Jan 2006 23:00:27 -0500

register_globals is often turned on to support legacy code and
CVE-2005-3390 makes code which by the documentation should be safe not so.

Consider:

> ; You should do your best to write your scripts so that they do not require
> ; register_globals to be on;  Using form variables as globals can easily lead
> ; to possible security problems, if the code is not very well thought of.

From the Debian-shipped php.ini, certainly does not warn that
register_globals itself is a security problem, but rather that poorly
written scripts are.


> but keep in mind that the directive itself isn't insecure but rather it's the
> misuse of it.

From <http://www.php.net/register_globals>. The page also notes that
reliance on the directive "was quite common and many people didn't even
know it existed and assumed it's just how PHP works." It then goes on to
explain how register_globals is unsafe --- examples which show the
well-known register_globals problem, not the CVE-2005-3390 one. Further,
one of the examples (29-3) could even be subverted by this bug!

Also, considering the number of Debian installations which probably have
register_globals turned on, and how that makes (as already pointed out
in this bug) anything using PEAR extremely vulnerable, I really think
this ought to be fixed in stable ASAP.

CVSS rates this as an 8 (high).
testing-security rates this as medium.

Message #90 received at 336645@bugs.debian.org (full text, mbox, reply):

From: Nick Jenkins <nickpj@gmail.com>

To: 336645@bugs.debian.org

Subject: Re: Bug#336645: Bug 336645: PHP 4.4.1 Security Fixes

Date: Thu, 12 Jan 2006 17:39:38 +1100

According to http://lwn.net/Articles/159103/ , it's looking like
Debian is the last major distro without a fix for this. Could perhaps
the recent Ubuntu updates ( http://lwn.net/Alerts/165505/ ), which
were for PHP 4.3.8, be of use to Sarge?

All the best,
Nick.

Message #95 received at 336645@bugs.debian.org (full text, mbox, reply):

From: Adam Conrad <adconrad@0c3.net>

To: Nick Jenkins <nickpj@gmail.com>, 336645@bugs.debian.org

Subject: Re: [php-maint] Bug#336645: Bug 336645: PHP 4.4.1 Security Fixes

Date: Fri, 13 Jan 2006 23:43:32 +1100

Nick Jenkins wrote:
> According to http://lwn.net/Articles/159103/ , it's looking like
> Debian is the last major distro without a fix for this. Could perhaps
> the recent Ubuntu updates ( http://lwn.net/Alerts/165505/ ), which
> were for PHP 4.3.8, be of use to Sarge?

Yes, I'm preparing updates for Debian matching those that I did for Ubuntu.

... Adam

Message #100 received at 336645-close@bugs.debian.org (full text, mbox, reply):

From: Adam Conrad <adconrad@0c3.net>

To: 336645-close@bugs.debian.org

Subject: Bug#336645: fixed in php4 4:4.4.2-1

Date: Wed, 18 Jan 2006 04:47:13 -0800

Source: php4
Source-Version: 4:4.4.2-1

We believe that the bug you reported is fixed in the latest version of
php4, which is due to be installed in the Debian FTP archive:

libapache-mod-php4_4.4.2-1_i386.deb
  to pool/main/p/php4/libapache-mod-php4_4.4.2-1_i386.deb
libapache2-mod-php4_4.4.2-1_i386.deb
  to pool/main/p/php4/libapache2-mod-php4_4.4.2-1_i386.deb
php4-cgi_4.4.2-1_i386.deb
  to pool/main/p/php4/php4-cgi_4.4.2-1_i386.deb
php4-cli_4.4.2-1_i386.deb
  to pool/main/p/php4/php4-cli_4.4.2-1_i386.deb
php4-common_4.4.2-1_i386.deb
  to pool/main/p/php4/php4-common_4.4.2-1_i386.deb
php4-curl_4.4.2-1_i386.deb
  to pool/main/p/php4/php4-curl_4.4.2-1_i386.deb
php4-dev_4.4.2-1_i386.deb
  to pool/main/p/php4/php4-dev_4.4.2-1_i386.deb
php4-domxml_4.4.2-1_i386.deb
  to pool/main/p/php4/php4-domxml_4.4.2-1_i386.deb
php4-gd_4.4.2-1_i386.deb
  to pool/main/p/php4/php4-gd_4.4.2-1_i386.deb
php4-ldap_4.4.2-1_i386.deb
  to pool/main/p/php4/php4-ldap_4.4.2-1_i386.deb
php4-mcal_4.4.2-1_i386.deb
  to pool/main/p/php4/php4-mcal_4.4.2-1_i386.deb
php4-mhash_4.4.2-1_i386.deb
  to pool/main/p/php4/php4-mhash_4.4.2-1_i386.deb
php4-mysql_4.4.2-1_i386.deb
  to pool/main/p/php4/php4-mysql_4.4.2-1_i386.deb
php4-odbc_4.4.2-1_i386.deb
  to pool/main/p/php4/php4-odbc_4.4.2-1_i386.deb
php4-pear_4.4.2-1_all.deb
  to pool/main/p/php4/php4-pear_4.4.2-1_all.deb
php4-pgsql_4.4.2-1_i386.deb
  to pool/main/p/php4/php4-pgsql_4.4.2-1_i386.deb
php4-recode_4.4.2-1_i386.deb
  to pool/main/p/php4/php4-recode_4.4.2-1_i386.deb
php4-snmp_4.4.2-1_i386.deb
  to pool/main/p/php4/php4-snmp_4.4.2-1_i386.deb
php4-sybase_4.4.2-1_i386.deb
  to pool/main/p/php4/php4-sybase_4.4.2-1_i386.deb
php4-xslt_4.4.2-1_i386.deb
  to pool/main/p/php4/php4-xslt_4.4.2-1_i386.deb
php4_4.4.2-1.diff.gz
  to pool/main/p/php4/php4_4.4.2-1.diff.gz
php4_4.4.2-1.dsc
  to pool/main/p/php4/php4_4.4.2-1.dsc
php4_4.4.2-1_all.deb
  to pool/main/p/php4/php4_4.4.2-1_all.deb
php4_4.4.2.orig.tar.gz
  to pool/main/p/php4/php4_4.4.2.orig.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 336645@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Adam Conrad <adconrad@0c3.net> (supplier of updated php4 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Wed, 18 Jan 2006 18:41:11 +1100
Source: php4
Binary: php4-sybase php4-recode php4-cgi libapache-mod-php4 php4-cli php4-dev php4-snmp libapache2-mod-php4 php4-odbc php4-xslt php4-mysql php4-domxml php4-gd php4-ldap php4-common php4 php4-curl php4-pear php4-mcal php4-mhash php4-pgsql
Architecture: source i386 all
Version: 4:4.4.2-1
Distribution: unstable
Urgency: low
Maintainer: Debian PHP Maintainers <pkg-php-maint@lists.alioth.debian.org>
Changed-By: Adam Conrad <adconrad@0c3.net>
Description: 
 libapache-mod-php4 - server-side, HTML-embedded scripting language (apache 1.3 module)
 libapache2-mod-php4 - server-side, HTML-embedded scripting language (apache 2.0 module)
 php4       - server-side, HTML-embedded scripting language (meta-package)
 php4-cgi   - server-side, HTML-embedded scripting language (CGI binary)
 php4-cli   - command-line interpreter for the php4 scripting language
 php4-common - Common files for packages built from the php4 source
 php4-curl  - CURL module for php4
 php4-dev   - Files for PHP4 module development
 php4-domxml - XMLv2 module for php4
 php4-gd    - GD module for php4
 php4-ldap  - LDAP module for php4
 php4-mcal  - MCAL calendar module for php4
 php4-mhash - MHASH module for php4
 php4-mysql - MySQL module for php4
 php4-odbc  - ODBC module for php4
 php4-pear  - PHP Extension and Application Repository (transitional package)
 php4-pgsql - PostgreSQL module for php4
 php4-recode - Character recoding module for php4
 php4-snmp  - SNMP module for php4
 php4-sybase - Sybase / MS SQL Server module for php4
 php4-xslt  - XSLT module for php4
Closes: 336004 336645 339577 341726 343399 343791
Changes: 
 php4 (4:4.4.2-1) unstable; urgency=low
 .
   * New upstream bugfix release, skipping the problematic 4.4.1 release:
     - Remove some PEAR cruft from 006-debian_quirks.patch, since we don't
       build PEAR from php4 anymore, and it conflicted with upstream diffs.
     - Remove 054-open_basedir_slash.patch, now integrated upstream.
     - Remove 055-gd_safe_mode_checks.patch, fixed differently upstream.
   * Many security vulns fixed (closes: #336645, #339577, #336004, #341726):
     - Fixes multiple cross-site-scripting vulnerabilities; CVE-2006-0208
     - Resolves multiple HTTP response splitting vulnerabilities, allowing
       arbitrary header injection via Set-Cookie headers; see CVE-2006-0207
     - Resolves a local denial of service in the apache2 SAPI, which can
       be triggered by using session.save_path in .htaccess; CVE-2005-3319
     - Resolves an infinite loop in the exif_read_data function which can
       be triggered with a specially-crafted JPEG image; CVE-2005-3353
     - Resolves an XSS vulnerability in the phpinfo function; CVE-2005-3388
     - Resolves a vulnerability in the parse_str function whereby a remote
       attacker can fool PHP into turning on register_globals, thus making
       applications vulnerable to global variable injections; CVE-2005-3389
     - Resolves a vulnerability in the RFC1867 file upload feature where, if
       register_globals is enabled, a remote attacker can modify the GLOBALS
       array with a multipart/form-data POST request; see CVE-2005-3390
     - Resolves numerous safe_mode and open_basedir bypasses; CVE-2005-3391
     - Resolves INI settings leaks in the apache2 SAPI, leading to safe_mode
       and open_basedir bypasses between virtual hosts; CVE-2005-3392
     - Resolves a CRLF injection vulnerability in the mb_send_mail function,
       allowing injection of arbitrary mail headers; see CVE-2005-3883
   * Bump libdb build-dep from 4.2 to 4.3, matching apache (closes: #343399)
   * Bump our MySQL build-dep to 5.0's libmysqlclient15-dev (closes: #343791)
   * Automate the process of getting the list of built-in modules into the
     package descriptions, so it stays fresh in the future (see: #341867)
   * Create 056-mime_magic_strings.patch, making the mime_magic extension
     more liberal about what mime-types is accepts, as well as making it skip
     over ones it dislikes, rather than disabling itself (see: #335674)
   * Add 057-no_apache_installed.patch, to stop spewing a mess of errors in
     configure because we don't have the apache binaries in the build chroot.
   * Fix small typo in the php4-xslt package description (see: #344816)
Files: 
 c30822bc794b738318164dce3cbd2813 1791 web optional php4_4.4.2-1.dsc
 a7ae7ed8f2edf1592bd94eab91c634fa 5461440 web optional php4_4.4.2.orig.tar.gz
 34f22a7d636ee5633e9d4bf1f359f700 98122 web optional php4_4.4.2-1.diff.gz
 f998715b32c378f3bf807f615a4af7b4 173814 web optional php4-common_4.4.2-1_i386.deb
 0cd21985bca4226e533c9a4731994397 1601042 web optional libapache-mod-php4_4.4.2-1_i386.deb
 8b5a78625cdc4d4bb2a303904a54ca46 1598430 web optional libapache2-mod-php4_4.4.2-1_i386.deb
 602fd72bae58292412d62c1acf0f57e4 3182264 web optional php4-cgi_4.4.2-1_i386.deb
 6c622e3396abfa063d157a4337c35d6d 1598306 web optional php4-cli_4.4.2-1_i386.deb
 1e57f095a587a7f74ec14bba5b6a6778 201146 devel optional php4-dev_4.4.2-1_i386.deb
 6d4f480b9e3e37068bc721b0e467da5e 19074 web optional php4-curl_4.4.2-1_i386.deb
 dd9fc2d0ead5371d973f5f7705351953 38808 web optional php4-domxml_4.4.2-1_i386.deb
 ffc438a188862049f180de60edc5e0c3 33182 web optional php4-gd_4.4.2-1_i386.deb
 06d007059020c6de7d0d2d90a15f4256 20714 web optional php4-ldap_4.4.2-1_i386.deb
 7e6496393a8325dd7aefcd7aa8c34eed 17656 web optional php4-mcal_4.4.2-1_i386.deb
 2d70d0fee6300a5d53bc11dda3fc8c49 8800 web optional php4-mhash_4.4.2-1_i386.deb
 1094ad0bdb7d8eae5ba36929db6747af 22084 web optional php4-mysql_4.4.2-1_i386.deb
 68a5c49262af6f869f6ea25206376db8 28126 web optional php4-odbc_4.4.2-1_i386.deb
 3ac3eaa6f73a1925d9d6bba0d0df09e0 37050 web optional php4-pgsql_4.4.2-1_i386.deb
 18f3ff80db3a44ae73ad9ceb45bc117d 8496 web optional php4-recode_4.4.2-1_i386.deb
 f200925fa384c1269f0aec042c5b4577 14104 web optional php4-snmp_4.4.2-1_i386.deb
 15c2e244fbd5c5b60a9bff4b2d11dc72 21530 web optional php4-sybase_4.4.2-1_i386.deb
 55f8951b13a84e15bd6a1806f232d43c 17006 web optional php4-xslt_4.4.2-1_i386.deb
 51b8a4bd2bb5892cb072ca3740529212 1154 web optional php4_4.4.2-1_all.deb
 69d6a539bce90b2f35d9740fbb7827aa 1168 web optional php4-pear_4.4.2-1_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDzjXzvjztR8bOoMkRAj8RAKDMLdBIx7pVMkP19wDX7qe5t9g0XACgwelS
KLrU8n+63+EODSHclBawMkQ=
=hvuD
-----END PGP SIGNATURE-----

Message #105 received at 336645@bugs.debian.org (full text, mbox, reply):

From: Nick Jenkins <nickpj@gmail.com>

To: 336645@bugs.debian.org

Subject: Re: Bug#336645: Bug 336645: PHP 4.4.1 Security Fixes

Date: Fri, 3 Feb 2006 17:55:39 +1100

Hi,

I'm sorry, but I have a question:

Is Sarge / stable going to get an update for these problems?

In particular, CVE-2005-3390 (GLOBALS array overwrite) for PHP, which
I believe Sarge / stable is vulnerable to (CVE entry says it applies
to "PHP 4.x up to 4.4.0"), and it is (IMO) a real-world security
problem that should be fixed in the stable release.

I had been assuming that the fix for this problem would go into Debian
3.1r2, the next stable release. However, the recent updates seem to be for
Testing.

Have I been following the wrong bug? (I couldn't see anything else
that looked suitable at http://qa.debian.org/bts-security.html#php4 )
Should I log a new bug specifically for Sarge, if I want an update for 3.1r2?
Or am I outright wrong, and these updates will be suitable for the
next Sarge release?

All the best,
Nick.

Message #110 received at 336645@bugs.debian.org (full text, mbox, reply):

From: Sam Morris <sam@robots.org.uk>

To: 336645@bugs.debian.org

Cc: adconrad@0c3.net

Subject: Fix for 336645?

Date: Fri, 2 Jun 2006 00:34:10 +0100

Is there any news about a fix for #336645 for Sarge?

Regards,

-- 
Sam Morris
http://robots.org.uk/

PGP key id 5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078

Send a report that this bug log contains spam.