Ubuntu
php4 package

php4: 4.3.10 fixes important security holes

Bug #11223 reported by Debian Bug Importer
4
Affects Status Importance Assigned to Milestone
php4 (Debian)
Fix Released
Unknown
php4 (Ubuntu)
Fix Released
High
Martin Pitt

Bug Description

Automatically imported from Debian bug report #285845 http://bugs.debian.org/285845

See original description
Revision history for this message
Debian Bug Importer (debzilla) wrote :

Automatically imported from Debian bug report #285845 http://bugs.debian.org/285845

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-Id: <email address hidden>
Date: Wed, 15 Dec 2004 23:13:20 +0100
From: Florian Weimer <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: php4: 4.3.10 fixes important security holes

Package: php4
Version: 4:4.3.9-2
Severity: grave
Tags: security upstream
Justification: user security hole

PHP 4.3.10 fixes several security bugs. The relevant part of the
release announcement follows.

stable might be affected, too. Let's hope vendor-sec has already sorted
this one out. 8-)

From: Ilia Alshanetsky <email address hidden>
Subject: [ANNOUNCE] PHP 4.3.10 & 5.0.3 Released!
To: <email address hidden>
Date: Wed, 15 Dec 2004 16:00:42 -0500
Message-ID: <email address hidden>
Enyo-Status: asn=7859

PHP Development Team would like to announce the immediate release of PHP
4.3.10 and 5.0.3. These are maintenance releases that in addition to
non-critical bug fixes address several very serious security issues.

These include the following:

CAN-2004-1018 - shmop_write() out of bounds memory write access.
CAN-2004-1018 - integer overflow/underflow in pack() and unpack() functions.
CAN-2004-1019 - possible information disclosure, double free and
negative reference index array underflow in deserialization code.
CAN-2004-1020 - addslashes not escaping \0 correctly.
CAN-2004-1063 - safe_mode execution directory bypass.
CAN-2004-1064 - arbitrary file access through path truncation.
CAN-2004-1065 - exif_read_data() overflow on long sectionname.
magic_quotes_gpc could lead to one level directory traversal with file
uploads.

All Users of PHP are strongly encouraged to upgrade to this release as
soon as possible.

[...]

Revision history for this message
In , Adam Conrad (adam-planetarytramp) wrote : Tagging

tags 285845 + woody
tags 285845 + sarge
thanks

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Thu, 16 Dec 2004 12:23:39 +1000 (EST)
From: "Adam Conrad" <email address hidden>
To: <email address hidden>
Subject: Tagging

tags 285845 + woody
tags 285845 + sarge
thanks

Revision history for this message
In , kryps (krypsilon) wrote : [PATCH,RFC] Backport of PHP 4.3.9 security fixes: pack()/unpack()

Hi!

I am not a Debian developer but we use Woody on our servers. The
latest PHP security holes affect us as well. I have backported the
security fix for the pack()/unpack() functions (attached).

Attached patch is against PHP 4.1.2-7. PHP 4.1.2-7+patch builds fine
in a Woody pbuilder and looks ok but I have not yet otherwise tested
it.

Comments? Should I try to backport the other security fixes as well?

Regards,

Hans
--
Hans Kratz

Revision history for this message
Debian Bug Importer (debzilla) wrote :
Download full text (3.3 KiB)

Message-ID: <email address hidden>
Date: Tue, 21 Dec 2004 16:26:00 +0100
From: Hans Kratz <email address hidden>
To: <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: [PATCH,RFC] Backport of PHP 4.3.9 security fixes: pack()/unpack()

------=_Part_305_25427426.1103642760216
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi!

I am not a Debian developer but we use Woody on our servers. The
latest PHP security holes affect us as well. I have backported the
security fix for the pack()/unpack() functions (attached).

Attached patch is against PHP 4.1.2-7. PHP 4.1.2-7+patch builds fine
in a Woody pbuilder and looks ok but I have not yet otherwise tested
it.

Comments? Should I try to backport the other security fixes as well?

Regards,

Hans
--
Hans Kratz

------=_Part_305_25427426.1103642760216
Content-Type: text/x-patch; name=php4-4.1.2-7-pack-unpack-fix.patch; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="php4-4.1.2-7-pack-unpack-fix.patch"

diff -purN php4-4.1.2-7.orig/ext/standard/pack.c php4-4.1.2-7/ext/standard/pack.c
--- php4-4.1.2-7.orig/ext/standard/pack.c 2001-08-11 19:03:37.000000000 +0200
+++ php4-4.1.2-7/ext/standard/pack.c 2004-12-19 14:55:26.000000000 +0100
@@ -49,6 +49,13 @@
 #include <netinet/in.h>
 #endif

+#define INC_OUTPUTPOS(a,b) \
+ if ((a) < 0 || ((INT_MAX - outputpos)/(b)) < (a)) { \
+ php_error(E_WARNING, "Type %c: integer overflow in format string", code); \
+ RETURN_FALSE; \
+ } \
+ outputpos += (a)*(b);
+
 /* Whether machine is little endian */
 char machine_little_endian;

@@ -216,39 +223,39 @@ PHP_FUNCTION(pack)

   switch ((int)code) {
    case 'h': case 'H': {
- outputpos += (arg + 1) / 2; /* 4 bit per arg */
+ INC_OUTPUTPOS((arg + 1) / 2,1) /* 4 bit per arg */
     break;
    }

    case 'a': case 'A':
    case 'c': case 'C':
    case 'x': {
- outputpos += arg; /* 8 bit per arg */
+ INC_OUTPUTPOS(arg,1) /* 8 bit per arg */
     break;
    }

    case 's': case 'S': case 'n': case 'v': {
- outputpos += arg * 2; /* 16 bit per arg */
+ INC_OUTPUTPOS(arg,2) /* 16 bit per arg */
     break;
    }

    case 'i': case 'I': {
- outputpos += arg * sizeof(int);
+ INC_OUTPUTPOS(arg,sizeof(int))
     break;
    }

    case 'l': case 'L': case 'N': case 'V': {
- outputpos += arg * 4; /* 32 bit per arg */
+ INC_OUTPUTPOS(arg,4) /* 32 bit per arg */
     break;
    }

    case 'f': {
- outputpos += arg * sizeof(float);
+ INC_OUTPUTPOS(arg,sizeof(float))
     break;
    }

    case 'd': {
- outputpos += arg * sizeof(double);
+ INC_OUTPUTPOS(arg,sizeof(double))
     break;
    }

@@ -615,6 +622,11 @@ PHP_FUNCTION(unpack)
     sprintf(n, "%.*s", namelen, name);
    }

+ if (size != 0 && size != -1 && INT_MAX - size + 1 < inputpos) {
+ php_error(E_WARNING, "Type %c: integer overflow", type);
+ inputpos = 0;
+ }
+
    if ((inputpos + size) <= inputlen) {
     switch ((int)type) {
      case 'a': case 'A': {
@@ -778,6 +790,10 @@ PHP_FUNCTION(unpack)
     }

     inputpos += size;
+ if (inputpos < 0) {
+ php_e...

Read more...

Revision history for this message
In , Martin Schulze (joey-infodrom) wrote :

Hans Kratz wrote:
> Hi!
>
> I am not a Debian developer but we use Woody on our servers. The
> latest PHP security holes affect us as well. I have backported the
> security fix for the pack()/unpack() functions (attached).
>
> Attached patch is against PHP 4.1.2-7. PHP 4.1.2-7+patch builds fine
> in a Woody pbuilder and looks ok but I have not yet otherwise tested
> it.
>
> Comments? Should I try to backport the other security fixes as well?

If you discover real security issues, yes please, or at least get
in touch with us so we don't miss it accidently.

You can only exploit the bug for which you provided a backport (didn't
the patch apply well?) if you write a malicious php script.
That's not an issue. You can do more with a malicious php script
with less effort.

Regards,

 Joey

--
All language designers are arrogant. Goes with the territory...
 -- Larry Wall

Revision history for this message
In , Florian Weimer (fw) wrote :

* Martin Schulze:

> You can only exploit the bug for which you provided a backport (didn't
> the patch apply well?) if you write a malicious php script.
> That's not an issue. You can do more with a malicious php script
> with less effort.

Unfortunately, PHP provides a feature called "safe mode". When turned
on, PHP makes the promise that PHP scripts are sandboxed. pack() and
unpack() are probably available in safe mode, too. (I haven't checked
this. Hans?)

Although I firmly believe that the "safe mode" feature cannot work as
advertised (simply because most C libraries that are accessible from
PHP code by default were never designed to be used in this fashion,
i.e. by untrusted callers), it's nevertheless an official feature of
PHP. Some of our users rely on it, so at least some form of advisory
is required.

A good advice (which is implemented by sufficiently clueful web
hosters) is running PHP scripts from different customers under
different user IDs. Of course, there's a performance penalty, and
it's hard to set up correctly: You need a UID transition at one point
because you can't run multiple Apache processes with different user
IDs unless you use IP-based virtual hosts.

Revision history for this message
In , kryps (krypsilon) wrote :

Hi!

On Wed, 22 Dec 2004 21:24:31 +0100, Florian Weimer <email address hidden> wrote:

> > You can only exploit the bug for which you provided a backport (didn't
> > the patch apply well?) if you write a malicious php script.

There was no official patch, only the diff I extracted from PHP 4.3
CVS, and it did not apply well but the changes to make it apply again
were trivial.

> > That's not an issue. You can do more with a malicious php script
> > with less effort.

It is not remotely exploitable, unless a script writer uses user input
for pack()/unpack() functions (unlikely).

> Unfortunately, PHP provides a feature called "safe mode". When turned
> on, PHP makes the promise that PHP scripts are sandboxed. pack() and
> unpack() are probably available in safe mode, too. (I haven't checked
> this. Hans?)

According to http://www.hardened-php.net/advisories/012004.txt you are
correct. So a PHP script writer can exploit this hole on a machine
running PHP in safe-mode to gain priviledges of the user running
apache. So it is a hole allowing local priviledge-elevation for PHP
installations running in safe mode.

Hans
--
Hans Kratz

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Wed, 22 Dec 2004 21:09:51 +0100
From: Martin Schulze <email address hidden>
To: Hans Kratz <email address hidden>
Cc: <email address hidden>, <email address hidden>,
 <email address hidden>
Subject: Re: [PATCH,RFC] Backport of PHP 4.3.9 security fixes: pack()/unpack()

Hans Kratz wrote:
> Hi!
>
> I am not a Debian developer but we use Woody on our servers. The
> latest PHP security holes affect us as well. I have backported the
> security fix for the pack()/unpack() functions (attached).
>
> Attached patch is against PHP 4.1.2-7. PHP 4.1.2-7+patch builds fine
> in a Woody pbuilder and looks ok but I have not yet otherwise tested
> it.
>
> Comments? Should I try to backport the other security fixes as well?

If you discover real security issues, yes please, or at least get
in touch with us so we don't miss it accidently.

You can only exploit the bug for which you provided a backport (didn't
the patch apply well?) if you write a malicious php script.
That's not an issue. You can do more with a malicious php script
with less effort.

Regards,

 Joey

--
All language designers are arrogant. Goes with the territory...
 -- Larry Wall

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Wed, 22 Dec 2004 21:24:31 +0100
From: Florian Weimer <email address hidden>
To: Martin Schulze <email address hidden>
Cc: Hans Kratz <email address hidden>, <email address hidden>, <email address hidden>
Subject: Re: [PATCH,RFC] Backport of PHP 4.3.9 security fixes: pack()/unpack()

* Martin Schulze:

> You can only exploit the bug for which you provided a backport (didn't
> the patch apply well?) if you write a malicious php script.
> That's not an issue. You can do more with a malicious php script
> with less effort.

Unfortunately, PHP provides a feature called "safe mode". When turned
on, PHP makes the promise that PHP scripts are sandboxed. pack() and
unpack() are probably available in safe mode, too. (I haven't checked
this. Hans?)

Although I firmly believe that the "safe mode" feature cannot work as
advertised (simply because most C libraries that are accessible from
PHP code by default were never designed to be used in this fashion,
i.e. by untrusted callers), it's nevertheless an official feature of
PHP. Some of our users rely on it, so at least some form of advisory
is required.

A good advice (which is implemented by sufficiently clueful web
hosters) is running PHP scripts from different customers under
different user IDs. Of course, there's a performance penalty, and
it's hard to set up correctly: You need a UID transition at one point
because you can't run multiple Apache processes with different user
IDs unless you use IP-based virtual hosts.

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Wed, 22 Dec 2004 21:53:54 +0100
From: Hans Kratz <email address hidden>
To: Florian Weimer <email address hidden>
Cc: Martin Schulze <email address hidden>, <email address hidden>,
 <email address hidden>
Subject: Re: [PATCH,RFC] Backport of PHP 4.3.9 security fixes: pack()/unpack()

Hi!

On Wed, 22 Dec 2004 21:24:31 +0100, Florian Weimer <email address hidden> wrote:

> > You can only exploit the bug for which you provided a backport (didn't
> > the patch apply well?) if you write a malicious php script.

There was no official patch, only the diff I extracted from PHP 4.3
CVS, and it did not apply well but the changes to make it apply again
were trivial.

> > That's not an issue. You can do more with a malicious php script
> > with less effort.

It is not remotely exploitable, unless a script writer uses user input
for pack()/unpack() functions (unlikely).

> Unfortunately, PHP provides a feature called "safe mode". When turned
> on, PHP makes the promise that PHP scripts are sandboxed. pack() and
> unpack() are probably available in safe mode, too. (I haven't checked
> this. Hans?)

According to http://www.hardened-php.net/advisories/012004.txt you are
correct. So a PHP script writer can exploit this hole on a machine
running PHP in safe-mode to gain priviledges of the user running
apache. So it is a hole allowing local priviledge-elevation for PHP
installations running in safe mode.

Hans
--
Hans Kratz

Revision history for this message
In , Adam Conrad (adconrad) wrote : Fixed in Sarge

tags 285845 -sarge
thanks

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <003c01c4e9f4$63f10b50$0301000a@0c3.net>
Date: Sat, 25 Dec 2004 06:08:51 +1000
From: "Adam Conrad" <adconrad@0c3.net>
To: <email address hidden>
Subject: Fixed in Sarge

tags 285845 -sarge
thanks

Revision history for this message
Martin Pitt (pitti) wrote :

Already fixed in Warty (USN-40-1) and Hoary.

Revision history for this message
In , Pekka Savola (pekkas) wrote : A backport of PHP fixes for 4.1.2

Hi,

I'm not a debian user myself, but I though some might be interested at
least.

For Fedora Legacy, I've created a backport of OpenPKG's php patch,
towards 4.1.2. It's attached.

I'd welcome more eyeballs looking at it, correct any mistakes and
omissions (if any :).

FWIW, I'm not sure if the patch is essential, but if you are worried
about maliscious or badly behaving scripts or safe-mode escalation, it
might be useful.

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Revision history for this message
In , Steve Kemp (skx) wrote :

On Wed, Jan 05, 2005 at 10:13:52PM +0200, Pekka Savola wrote:
> I'd welcome more eyeballs looking at it, correct any mistakes and
> omissions (if any :).

  Looks good, except this bit seems dodgy:

- memcpy(ptr, CWDG(cwd).cwd, CWDG(cwd).cwd_length);
- ptr += CWDG(cwd).cwd_length;
+ *ptr++ = '\'';
+ while (dir_length > 0) {
+ switch (*dir) {
+ case '\'':
+ *ptr++ = '\'';
+ *ptr++ = '\\';
+ *ptr++ = '\'';
+ /* fall-through */

  Is ptr going to be big enough? For every ' character it's incremented
 several times.

  This may become clear when more context is present, but it's the
 only thing that I'd be wanting to look more closely at.

Steve
-

Revision history for this message
Debian Bug Importer (debzilla) wrote :
Download full text (12.7 KiB)

Message-ID: <email address hidden>
Date: Wed, 5 Jan 2005 22:13:52 +0200 (EET)
From: Pekka Savola <email address hidden>
To: Florian Weimer <email address hidden>
cc: Martin Schulze <email address hidden>, <email address hidden>,
   <email address hidden>
Subject: A backport of PHP fixes for 4.1.2

--1589707168-1521012788-1104956032=:13425
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

Hi,

I'm not a debian user myself, but I though some might be interested at
least.

For Fedora Legacy, I've created a backport of OpenPKG's php patch,
towards 4.1.2. It's attached.

I'd welcome more eyeballs looking at it, correct any mistakes and
omissions (if any :).

FWIW, I'm not sure if the patch is essential, but if you are worried
about maliscious or badly behaving scripts or safe-mode escalation, it
might be useful.

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--1589707168-1521012788-1104956032=:13425
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="php-4.1.2-openpkg-backport-v2.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <email address hidden>
Content-Description:
Content-Disposition: attachment; filename="php-4.1.2-openpkg-backport-v2.patch"

U2VjdXJpdHkgRml4ZXMgKE9wZW5QS0ctMjAwNC4wNTMtcGhwKToNCg0KbyBD
QU4tMjAwNC0xMDE4Og0KICBzaG1vcF93cml0ZSgpIG91dCBvZiBib3VuZHMg
bWVtb3J5IHdyaXRlIGFjY2Vzcy4NCiAgKGV4dC9zaG1vcC9zaG1vcC5jKQ0K
DQpvIENBTi0yMDA0LTEwMTg6DQogIGludGVnZXIgb3ZlcmZsb3cvdW5kZXJm
bG93IGluIHBhY2soKSBhbmQgdW5wYWNrKCkgZnVuY3Rpb25zLg0KICAobWFp
bi9waHAuaCwgZXh0L3N0YW5kYXJkL3BhY2suYykNCg0KbyBDQU4tMjAwNC0x
MDE5Og0KICBwb3NzaWJsZSBpbmZvcm1hdGlvbiBkaXNjbG9zdXJlLCBkb3Vi
bGUgZnJlZSBhbmQgbmVnYXRpdmUgcmVmZXJlbmNlDQogIGluZGV4IGFycmF5
IHVuZGVyZmxvdyBpbiBkZXNlcmlhbGl6YXRpb24gY29kZS4NCiAgKGV4dC9z
dGFuZGFyZC92YXJfdW5zZXJpYWxpemVyLnJlLCBleHQvc3RhbmRhcmQvdmFy
X3Vuc2VyaWFsaXplci5jKQ0KICAqKioqIE5PVCBBUFBMSUNBQkxFIElOIDQu
MS4yISEgKioqKg0KDQpvIENBTi0yMDA0LTEwMjA6DQogIGFkZHNsYXNoZXMo
KSBub3QgZXNjYXBpbmcgXDAgY29ycmVjdGx5Lg0KICAoZXh0L3N0YW5kYXJk
L3N0cmluZy5jKQ0KICAqKioqIE5PVCBORUNDRVNTQVJZIElOIFBIUCA0LjMu
OCEhICoqKioNCg0KbyBDQU4tMjAwNC0xMDYzOg0KICBzYWZlX21vZGUgZXhl
Y3V0aW9uIGRpcmVjdG9yeSBieXBhc3MuDQogIChleHQvc3RhbmRhcmQvbGlu
ay5jLCBUU1JNL3Rzcm1fdmlydHVhbF9jd2QuYykNCg0KbyBDQU4tMjAwNC0x
MDY0Og0KICBhcmJpdHJhcnkgZmlsZSBhY2Nlc3MgdGhyb3VnaCBwYXRoIHRy
dW5jYXRpb24uDQogIChtYWluL3NhZmVfbW9kZS5jKQ0KDQpvIENBTi0yMDA0
LTEwNjU6DQogIGV4aWZfcmVhZF9kYXRhKCkgb3ZlcmZsb3cgb24gbG9uZyBz
ZWN0aW9ubmFtZS4NCiAgKGV4dC9leGlmL2V4aWYuYykNCiAgKioqKiBOT1Qg
QVBQTElDQUJMRSBJTiA0LjEuMiEhICoqKioNCg0KbyBYWFgtWFhYWC1YWFhY
Og0KICBtYWdpY19xdW90ZXNfZ3BjIGNvdWxkIGxlYWQgdG8gb25lIGxldmVs
IGRpcmVjdG9yeSB0cmF2ZXJzYWwgd2l0aA0KICBmaWxlIHVwbG9hZHMuDQog
IChtYWluL3JmYzE4NjcuYykNCiAgKioqKiBQQVJUUyBPRiBUSEUgUEFUQ0gg
Tk9UIEFQUExJQ0FCTEUgSU4gNC4xLjIhISAqKioqDQoNCmRpZmYgLWF1ciBw
aHAtNC4xLjItb3JpZy9leHQvc2htb3Avc2htb3AuYyBwaHAtNC4xLjIvZXh0
L3NobW9wL3NobW9wLmMNCi0tLSBwaHAtNC4xLjItb3JpZy9leHQvc2htb3Av
c2htb3AuYwkyMDAyLTAxLTA5IDEwOjQwOjEzLjAwMDAwMDAwMCArMDIwMA0K
KysrIHBocC00LjEuMi9leHQvc2htb3Avc2htb3AuYwkyMDA1LTAxLTA1IDIx
OjI0O...

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Wed, 5 Jan 2005 20:34:24 +0000
From: Steve Kemp <email address hidden>
To: Pekka Savola <email address hidden>
Cc: Florian Weimer <email address hidden>, Martin Schulze <email address hidden>,
 <email address hidden>, <email address hidden>
Subject: Re: A backport of PHP fixes for 4.1.2

On Wed, Jan 05, 2005 at 10:13:52PM +0200, Pekka Savola wrote:
> I'd welcome more eyeballs looking at it, correct any mistakes and
> omissions (if any :).

  Looks good, except this bit seems dodgy:

- memcpy(ptr, CWDG(cwd).cwd, CWDG(cwd).cwd_length);
- ptr += CWDG(cwd).cwd_length;
+ *ptr++ = '\'';
+ while (dir_length > 0) {
+ switch (*dir) {
+ case '\'':
+ *ptr++ = '\'';
+ *ptr++ = '\\';
+ *ptr++ = '\'';
+ /* fall-through */

  Is ptr going to be big enough? For every ' character it's incremented
 several times.

  This may become clear when more context is present, but it's the
 only thing that I'd be wanting to look more closely at.

Steve
-

Revision history for this message
In , Pekka Savola (pekkas) wrote :

Hi,

On Wed, 5 Jan 2005, Steve Kemp wrote:
> On Wed, Jan 05, 2005 at 10:13:52PM +0200, Pekka Savola wrote:
>> I'd welcome more eyeballs looking at it, correct any mistakes and
>> omissions (if any :).
>
> Looks good, except this bit seems dodgy:

Thanks for looking!

> - memcpy(ptr, CWDG(cwd).cwd, CWDG(cwd).cwd_length);
> - ptr += CWDG(cwd).cwd_length;
> + *ptr++ = '\'';
> + while (dir_length > 0) {
> + switch (*dir) {
> + case '\'':
> + *ptr++ = '\'';
> + *ptr++ = '\\';
> + *ptr++ = '\'';
> + /* fall-through */
>
>
> Is ptr going to be big enough? For every ' character it's incremented
> several times.
>
> This may become clear when more context is present, but it's the
> only thing that I'd be wanting to look more closely at.

Good question. The code fragment comes from 4.3.10.. [*] So, if you
assume the php developers thought that through, and nothing big has
changed between 4.1.2 and 4.3.8 (the patch applies as is) it should be
OK (that's good enough for me :). If not..

[*] among others,
http://cvs.php.net/diff.php/TSRM/tsrm_virtual_cwd.c?r1=1.41.2.7&r2=1.41.2.8&ty=u

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Thu, 6 Jan 2005 10:16:55 +0200 (EET)
From: Pekka Savola <email address hidden>
To: Steve Kemp <email address hidden>
cc: Florian Weimer <email address hidden>, Martin Schulze <email address hidden>,
 <email address hidden>, <email address hidden>
Subject: Re: A backport of PHP fixes for 4.1.2

Hi,

On Wed, 5 Jan 2005, Steve Kemp wrote:
> On Wed, Jan 05, 2005 at 10:13:52PM +0200, Pekka Savola wrote:
>> I'd welcome more eyeballs looking at it, correct any mistakes and
>> omissions (if any :).
>
> Looks good, except this bit seems dodgy:

Thanks for looking!

> - memcpy(ptr, CWDG(cwd).cwd, CWDG(cwd).cwd_length);
> - ptr += CWDG(cwd).cwd_length;
> + *ptr++ = '\'';
> + while (dir_length > 0) {
> + switch (*dir) {
> + case '\'':
> + *ptr++ = '\'';
> + *ptr++ = '\\';
> + *ptr++ = '\'';
> + /* fall-through */
>
>
> Is ptr going to be big enough? For every ' character it's incremented
> several times.
>
> This may become clear when more context is present, but it's the
> only thing that I'd be wanting to look more closely at.

Good question. The code fragment comes from 4.3.10.. [*] So, if you
assume the php developers thought that through, and nothing big has
changed between 4.1.2 and 4.3.8 (the patch applies as is) it should be
OK (that's good enough for me :). If not..

[*] among others,
http://cvs.php.net/diff.php/TSRM/tsrm_virtual_cwd.c?r1=1.41.2.7&r2=1.41.2.8&ty=u

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Revision history for this message
In , Martin Schulze (joey-infodrom) wrote :

Pekka Savola wrote:
> I'm not a debian user myself, but I though some might be interested at
> least.
>
> For Fedora Legacy, I've created a backport of OpenPKG's php patch,
> towards 4.1.2. It's attached.

Thanks.

> Security Fixes (OpenPKG-2004.053-php):
>
> o CAN-2004-1018:
> shmop_write() out of bounds memory write access.
> (ext/shmop/shmop.c)

Withdrawn, not considered as vulnreability since it would require
a malicious script and you can do more evil things much easier with
a malicious script.

>
> o CAN-2004-1018:
> integer overflow/underflow in pack() and unpack() functions.
> (main/php.h, ext/standard/pack.c)

Same as above.

> o CAN-2004-1019:
> possible information disclosure, double free and negative reference
> index array underflow in deserialization code.
> (ext/standard/var_unserializer.re, ext/standard/var_unserializer.c)
> **** NOT APPLICABLE IN 4.1.2!! ****

Real vulnerability, not applicable to woody.

> o CAN-2004-1020:
> addslashes() not escaping \0 correctly.
> (ext/standard/string.c)
> **** NOT NECCESSARY IN PHP 4.3.8!! ****

Withdrawn, not considered as vulnreability since it would require
a malicious script and you can do more evil things much easier with
a malicious script.

> o CAN-2004-1063:
> safe_mode execution directory bypass.
> (ext/standard/link.c, TSRM/tsrm_virtual_cwd.c)

Same as above.

> o CAN-2004-1064:
> arbitrary file access through path truncation.
> (main/safe_mode.c)

Same as above.

> o CAN-2004-1065:
> exif_read_data() overflow on long sectionname.
> (ext/exif/exif.c)
> **** NOT APPLICABLE IN 4.1.2!! ****

Real vulnerability, not applicable to woody.

> o XXX-XXXX-XXXX:
> magic_quotes_gpc could lead to one level directory traversal with
> file uploads.
> (main/rfc1867.c)
> **** PARTS OF THE PATCH NOT APPLICABLE IN 4.1.2!! ****

No real vulnerability, only precaution code.

All bugs are bugs and should be fixed in the unstable branch of PHP.

However, when they can only be exploited by a malicious PHP script,
we don't need to fix them, since a malicious PHP script requires
an authorised person to write code and he could also write system(foo)
to get shell access. PHP has thousands of such bugs.

The only real vulnerabilityes are identified as CAN-2004-1019 and
CAN-2004-1065 and interestingly these don't apply to the version
of PHP in woody.

Hence, no update to woody (=Debian stable) is required.

Regards,

 Joey

--
In the beginning was the word, and the word was content-type: text/plain

Please always Cc to me when replying to me on the lists.

Revision history for this message
In , Florian Weimer (fw) wrote :

* Martin Schulze:

>> Security Fixes (OpenPKG-2004.053-php):
>>
>> o CAN-2004-1018:
>> shmop_write() out of bounds memory write access.
>> (ext/shmop/shmop.c)
>
> Withdrawn, not considered as vulnreability since it would require
> a malicious script and you can do more evil things much easier with
> a malicious script.

Huh? What about safe_mode? Does CVE officially declare safe_mode as
fundamentally insecure?

Revision history for this message
In , Martin Schulze (joey-infodrom) wrote :

Florian Weimer wrote:
> * Martin Schulze:
>
> >> Security Fixes (OpenPKG-2004.053-php):
> >>
> >> o CAN-2004-1018:
> >> shmop_write() out of bounds memory write access.
> >> (ext/shmop/shmop.c)
> >
> > Withdrawn, not considered as vulnreability since it would require
> > a malicious script and you can do more evil things much easier with
> > a malicious script.
>
> Huh? What about safe_mode? Does CVE officially declare safe_mode as
> fundamentally insecure?

Yes (except that it's not CVE who declared but vendor-sec).

Regards,

 Joey

--
In the beginning was the word, and the word was content-type: text/plain

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Sun, 9 Jan 2005 11:18:03 +0100
From: Martin Schulze <email address hidden>
To: Pekka Savola <email address hidden>
Cc: Florian Weimer <email address hidden>, <email address hidden>,
 <email address hidden>
Subject: Re: A backport of PHP fixes for 4.1.2

Pekka Savola wrote:
> I'm not a debian user myself, but I though some might be interested at
> least.
>
> For Fedora Legacy, I've created a backport of OpenPKG's php patch,
> towards 4.1.2. It's attached.

Thanks.

> Security Fixes (OpenPKG-2004.053-php):
>
> o CAN-2004-1018:
> shmop_write() out of bounds memory write access.
> (ext/shmop/shmop.c)

Withdrawn, not considered as vulnreability since it would require
a malicious script and you can do more evil things much easier with
a malicious script.

>
> o CAN-2004-1018:
> integer overflow/underflow in pack() and unpack() functions.
> (main/php.h, ext/standard/pack.c)

Same as above.

> o CAN-2004-1019:
> possible information disclosure, double free and negative reference
> index array underflow in deserialization code.
> (ext/standard/var_unserializer.re, ext/standard/var_unserializer.c)
> **** NOT APPLICABLE IN 4.1.2!! ****

Real vulnerability, not applicable to woody.

> o CAN-2004-1020:
> addslashes() not escaping \0 correctly.
> (ext/standard/string.c)
> **** NOT NECCESSARY IN PHP 4.3.8!! ****

Withdrawn, not considered as vulnreability since it would require
a malicious script and you can do more evil things much easier with
a malicious script.

> o CAN-2004-1063:
> safe_mode execution directory bypass.
> (ext/standard/link.c, TSRM/tsrm_virtual_cwd.c)

Same as above.

> o CAN-2004-1064:
> arbitrary file access through path truncation.
> (main/safe_mode.c)

Same as above.

> o CAN-2004-1065:
> exif_read_data() overflow on long sectionname.
> (ext/exif/exif.c)
> **** NOT APPLICABLE IN 4.1.2!! ****

Real vulnerability, not applicable to woody.

> o XXX-XXXX-XXXX:
> magic_quotes_gpc could lead to one level directory traversal with
> file uploads.
> (main/rfc1867.c)
> **** PARTS OF THE PATCH NOT APPLICABLE IN 4.1.2!! ****

No real vulnerability, only precaution code.

All bugs are bugs and should be fixed in the unstable branch of PHP.

However, when they can only be exploited by a malicious PHP script,
we don't need to fix them, since a malicious PHP script requires
an authorised person to write code and he could also write system(foo)
to get shell access. PHP has thousands of such bugs.

The only real vulnerabilityes are identified as CAN-2004-1019 and
CAN-2004-1065 and interestingly these don't apply to the version
of PHP in woody.

Hence, no update to woody (=Debian stable) is required.

Regards,

 Joey

--
In the beginning was the word, and the word was content-type: text/plain

Please always Cc to me when replying to me on the lists.

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Sun, 09 Jan 2005 11:29:56 +0100
From: Florian Weimer <email address hidden>
To: Martin Schulze <email address hidden>
Cc: Pekka Savola <email address hidden>, <email address hidden>, <email address hidden>
Subject: Re: A backport of PHP fixes for 4.1.2

* Martin Schulze:

>> Security Fixes (OpenPKG-2004.053-php):
>>
>> o CAN-2004-1018:
>> shmop_write() out of bounds memory write access.
>> (ext/shmop/shmop.c)
>
> Withdrawn, not considered as vulnreability since it would require
> a malicious script and you can do more evil things much easier with
> a malicious script.

Huh? What about safe_mode? Does CVE officially declare safe_mode as
fundamentally insecure?

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Sun, 9 Jan 2005 11:49:28 +0100
From: Martin Schulze <email address hidden>
To: Florian Weimer <email address hidden>
Cc: Pekka Savola <email address hidden>, <email address hidden>,
 <email address hidden>
Subject: Re: A backport of PHP fixes for 4.1.2

Florian Weimer wrote:
> * Martin Schulze:
>
> >> Security Fixes (OpenPKG-2004.053-php):
> >>
> >> o CAN-2004-1018:
> >> shmop_write() out of bounds memory write access.
> >> (ext/shmop/shmop.c)
> >
> > Withdrawn, not considered as vulnreability since it would require
> > a malicious script and you can do more evil things much easier with
> > a malicious script.
>
> Huh? What about safe_mode? Does CVE officially declare safe_mode as
> fundamentally insecure?

Yes (except that it's not CVE who declared but vendor-sec).

Regards,

 Joey

--
In the beginning was the word, and the word was content-type: text/plain

Revision history for this message
In , Florian Weimer (fw) wrote :

* Martin Schulze:

>> Huh? What about safe_mode? Does CVE officially declare safe_mode as
>> fundamentally insecure?
>
> Yes (except that it's not CVE who declared but vendor-sec).

Okay, this actually good news.

Shall I write a draft DSA and some documentation patches? Some of our
users rely on this feature and are not aware of its defects.

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Sun, 09 Jan 2005 13:00:15 +0100
From: Florian Weimer <email address hidden>
To: Martin Schulze <email address hidden>
Cc: Pekka Savola <email address hidden>, <email address hidden>, <email address hidden>
Subject: Re: A backport of PHP fixes for 4.1.2

* Martin Schulze:

>> Huh? What about safe_mode? Does CVE officially declare safe_mode as
>> fundamentally insecure?
>
> Yes (except that it's not CVE who declared but vendor-sec).

Okay, this actually good news.

Shall I write a draft DSA and some documentation patches? Some of our
users rely on this feature and are not aware of its defects.

Revision history for this message
In , Martin Schulze (joey-infodrom) wrote :

Florian Weimer wrote:
> >> Huh? What about safe_mode? Does CVE officially declare safe_mode as
> >> fundamentally insecure?
> >
> > Yes (except that it's not CVE who declared but vendor-sec).
>
> Okay, this actually good news.

Hmm. I'm not sure that "safe_mode is fundamentally broken" is good news,
but it's the truth...

> Shall I write a draft DSA and some documentation patches? Some of our
> users rely on this feature and are not aware of its defects.

Please do. I think a good documentation on why/how safe_mode is
broken would be good to be added to www.debian.org/security/<somewhere>,
same as chroot-is-no-jail.

Regards,

 Joey

--
In the beginning was the word, and the word was content-type: text/plain

Please always Cc to me when replying to me on the lists.

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Sun, 9 Jan 2005 13:32:28 +0100
From: Martin Schulze <email address hidden>
To: Florian Weimer <email address hidden>
Cc: Pekka Savola <email address hidden>, <email address hidden>,
 <email address hidden>
Subject: Re: A backport of PHP fixes for 4.1.2

Florian Weimer wrote:
> >> Huh? What about safe_mode? Does CVE officially declare safe_mode as
> >> fundamentally insecure?
> >
> > Yes (except that it's not CVE who declared but vendor-sec).
>
> Okay, this actually good news.

Hmm. I'm not sure that "safe_mode is fundamentally broken" is good news,
but it's the truth...

> Shall I write a draft DSA and some documentation patches? Some of our
> users rely on this feature and are not aware of its defects.

Please do. I think a good documentation on why/how safe_mode is
broken would be good to be added to www.debian.org/security/<somewhere>,
same as chroot-is-no-jail.

Regards,

 Joey

--
In the beginning was the word, and the word was content-type: text/plain

Please always Cc to me when replying to me on the lists.

Revision history for this message
In , Adam Conrad (adconrad) wrote : Closing

Closing this bug, as Joey has indicated it's not relevant to woody, and
sid and sarge have both been fixed.

... Adam

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Sat, 5 Feb 2005 23:50:02 +1000 (EST)
From: "Adam Conrad" <adconrad@0c3.net>
To: <email address hidden>
Subject: Closing

Closing this bug, as Joey has indicated it's not relevant to woody, and
sid and sarge have both been fixed.

... Adam

Bug Watch Updater (bug-watch-updater)
Changed in php4:
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.