<!-- SBZ_reproduce  -->
see above.

From: Mark J Cox <mjc@redhat.com> 
To: Stefan Esser <sesser@suspekt.org> 
Cc: vendor-sec@lst.de, security@php.net 
Subject: Re: [vendor-sec] PHP: Multiple vulnerabilities 
Errors-To: vendor-sec-admin@lst.de 
Date: Sun, 28 Nov 2004 15:55:01 +0000 (GMT) 
 
Hi Stefan, is the plan to hold off disclosing the exact issues (advisory 
etc) until the releases are out?  Here are some CVE names for the release 
notes etc: 
 
>[01] ext/shmop/shmop.c - shmop_write() out of bounds memory write access 
>[02] ext/standard/pack.c - pack() integer overflows leading to 
>                          heap bufferoverflow 
>    ext/standard/pack.c - unpack() integer underflow leading to 
>                          heap info leak 
 
= CAN-2004-1018  (all bounds/over/under flaws) 
 
>[03] etx/standard/var_unserializer.c 
>    etx/standard/var_unserializer.re - possible information 
>                                       leaks/overflows 
 
= CAN-2004-1019 
 
(possibly more than one flaw type here - but I didn't go through the 
patch in detail, one CVE for this for now) 
 
>[04] main/rfc1867.c - magic_quotes_gpc could lead to one level directory 
>                     traversal (attention: the filename argument should 
>                     be handled by any web application as potential 
>                     malicious user input and therefore never used 
>                     directly anyway. ) 
 
I'd say this was then a preventative fix to protect against bad scripts; 
so no CVE name.  I can be convinced otherwise :) 
 
>[05] ext/standard/string.c - addslashes (and therefore magic_quotes_gpc) 
>                            does not properly escape \0 
 
= CAN-2004-1020.  How would this one being exploited? 
 
Mark 
 

Do we have this one on our list too? Or is it already fixed? 
 
From: Gyan chawdhary <gunnu45@hotmail.com> 
To: bugtraq@securityfocus.com 
Cc: vuln-dev@securityfocus.com.com, da@securityfocus.com 
Subject: php 4.3.7 memory limit POC exploit 
Date: Fri, 26 Nov 2004 06:47:15 +0000 
 
[-- Anhang #1 --] 
[-- Typ: text/plain, Kodierung: quoted-printable, GröÃe: 0,4K --] 
 
Hi all, 
 
Attached  is an old POC I had written for the php memory limit vuln. It 
works 
well on php 4.3.7 with 2.0.49 apache. But its not an elegant solution. 
 
http://www.felinemenace.org/~gyan/phpnolimit.c 
 
have fun, 
 
Gyan 
 
_________________________________________________________________ 
Choose what you want to read. Protect your mail from spam. 
 

Tomas? 

ping! 

I have prepared patches for SL 8.2, 9.0, 9.1, 9.2. Now I'm working on 8.1.

The memory limit vuln. has been already fixed.
The 'addslashes' is no issue for us.
I have submitted fixed packages, sles9 also contains
fix for bug 61664 and all packages except for SL 9.2
also contain fix for bug 63431.

* This comment was added by mail.
Date: Tue, 7 Dec 2004 16:02:49 +0000
From: Joe Orton <jorton@redhat.com>
To: vendor-sec@lst.de
Subject: Re: [vendor-sec] PHP: Multiple vulnerabilities - Here the full mail...

After some further analysis, we're going to withdraw some of these CVE
name assignments.  Of the 11 issues Stefan reported recently we'll
assign only two CVE names, under the policy that PHP scripts should be
considered to execute with the permissions of the PHP interpreter.  The
others are not considered security issues:

CAN-2004-1019 is assigned and covers three unserializer bugs:

[03] etx/standard/var_unserializer.re - possible information leaks/overflows
[06] etx/standard/var_unserializer.re - negative reference index array underflow
[07] etx/standard/var_unserializer.re - reference to already freed array element

and CAN-2004-1065 is assigned and covers parsing of exif images:

[11] ext/exif/exif.c - exif_read_data() overflow on long sectionname

I'll follow up with the complete patches for those sometime this week.

To recap on the rest:

[01] ext/shmop/shmop.c - shmop_write() out of bounds memory write access
[02] ext/standard/pack.c - pack() integer overflows leading to heap bufferoverflow
     ext/standard/pack.c - unpack() integer underflow leading to heap info leak
 -> reqires malicious script: CAN-2004-1018 is WITHDRAWN

[04] main/rfc1867.c - magic_quotes_gpc could lead to one level directory traversal
 -> no known direct security implications (no CVE name assigned)

[05] ext/standard/string.c - addslashes (and therefore magic_quotes_gpc)
                            does not properly escape \0
 -> no known direct security implications, CAN-2004-1020 WITHDRAWN

[08] TSRM/tsrm_virtual_cwd.c - virtual_popen() safe_mode_exec_dir bypass
[09] TSRM/tsrm_virtual_cwd.c - virtual_file_ex() does not protect itself
                               against malfunctional realpath()
[10] main/safe_mode.c - Overlong filename fools security checks
 -> requires malicious script: CAN-2004-1063, CAN-2004-1064 both WITHDRAWN
_______________________________________________
Vendor Security mailing list
Vendor Security@lst.de
https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec

* This comment was added by mail.
We missed #11, right?

Date: Fri, 03 Dec 2004 17:51:36 +0100
From: Stefan Esser <sesser@suspekt.org>
To: Joe Orton <jorton@redhat.com>
Cc: Mark J Cox <mjc@redhat.com>, vendor-sec@lst.de, security@php.net
Subject: Re: [vendor-sec] PHP: Multiple vulnerabilities - Here the full mail...

Hello again,

[07] is now fixed in our CVS

http://cvs.php.net/diff.php/php-src/ext/standard/var_unserializer.re?f=&r1=0&tr1=1.11.4.6&ty=h&r2=0&tr2=1.11.4.8



and well I forgot to mention one possible overflow in the exif extension 
triggerable by a malicious image file.

[11] ext/exif/exif.c - exif_read_data() overflow on long sectionname

Imagefile containing malicious exif data can trigger stack overflow.

http://cvs.php.net/diff.php/php-src/ext/exif/exif.c?r1=1.118.2.28&r2=1.118.2.29&ty=h

Credits: Ilia Alshanetsky


Greetings
Stefan Esser

-- 
--------------------------------------------------------------------------
 Stefan Esser                                        s.esser@e-matters.de
 e-matters Security                         http://security.e-matters.de/

 GPG-Key                gpg --keyserver pgp.mit.edu --recv-key 0x15ABDA78
 Key fingerprint       7806 58C8 CFA8 CE4A 1C2C  57DD 4AE1 795E 15AB DA78
--------------------------------------------------------------------------
 Did I help you? Consider a gift:            http://wishlist.suspekt.org/
--------------------------------------------------------------------------
_______________________________________________
Vendor Security mailing list
Vendor Security@lst.de
https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec

Yes

Can you please include the missing patch and submit new packages? 

advisories and updates are out now on php.net ...  

* This comment was added by mail.
Two testcases are included in this advisory.

Date: Wed, 15 Dec 2004 22:32:54 +0100
From: Martin Eiszner <martin@websec.org>
To: bugtraq@securityfocus.com
Subject: php unserialize


==============================================================
SEC-CONSULT Security Advisory PHP - 4.3.9 unserialize function
======================OOOOOOOOOOOO============================

Product:        PHP 4.3.9 (Win32/Unix)
Remarks:        no other Versions tested but very likely vulnerable

Vulnerablities:

- Data Segment memory corruption
- Information disclosure / Memory dumping

Vendor:         PHP (http://www.php.net/)
Vendor-Status:  vendor contacted (19.11.2004)
Vendor-Patchs:  vendor has released bugfixed versions

Object: ---

Exploitable:
Local:          ---
Remote:         PARTIAL (OS-dependent)

============
Introduction
============

Visit "http://www.php.net" for additional information.


=====================
Vulnerability Details
=====================


1) Memory Corruption / buffer overflow
======================================

FUNCTION:
unserialize (http://at.php.net/manual/en/function.unserialize.php)

DESCRIPTION:
Insufficient input validation of serialized strings lead to memory corruption and information disclosre.

EXAMPLE script - "Segfault":
---cut here---
<?
$s = 's:9999999:"A";"';
$a = unserialize($s);
print $a;
?>
---cut here---

REMARKS:
leads to arbitrary code execution and file/information disclosure.


EXAMPLE script - "Memory Dump":
---cut here---
<?
// session- and stuff
$secret_username="uaaaa";
$secret_password="hoschi";

// stuff
// $c = $_COOKIE ['crypted_stuff']
// $c = some cookie
/* simplyfied --> userinput */ $c = 's:30000:"crap";';

$userdata = unserialize($c);
//
// check $userdata stuff
// for some reason output $userdata
print $userdata . "\n is NOT valid !!\n";

// stuff
?>
---cut here---


REMARKS:
Could theoretically be used to circumvent safe-mode and/or gain sensitive information about script- and memory areas.


===============
GENERAL REMARKS
===============
We would like to apologize in advance for potential nonconformities and/or known issues.

=========================================================================================================================
FOR SOME STRANGE REASONS HARDENED-PHP.NET HAS RELEASED THIS ADVISORY TODAY TOGETHER WITH A BUNCH OF OTHER VULNERABILITIES
=========================================================================================================================

====================
Recommended Hotfixes
====================

Vendor-Patches: vendor has released bugfixed versions

=======
Contact
=======

SEC-CONSULT
Austria / EUROPE
m.eiszner@sec-consult.com


EOF Martin Eiszner / @2004m.eiszner@sec-consult.com

submitted new packages

Thanks! 
 
The "advisory" in #13 might be bogus. 

* This comment was added by mail.
Testcase for the addslashes() bug.

Date: Thu, 16 Dec 2004 15:09:55 +0100 (CET)
From: Daniel Fabian <research@sec-consult.com>
To: full-disclosure@lists.netsys.com
Cc: bugtraq@securityfocus.com
Subject: PHP Input Validation Vulnerabilities
Reply-To: df@sec-consult.com

-------------------------------------------------------------------------
|                PHP Input Validation Vulnerabilities                   |
-------------------------------------------------------------------------

Date: 12-16-2004
Author: Daniel Fabian
Product: PHP
Vendor: PHP (http://www.php.net)
Vendor-Status: vendor contacted
Vendor-Patches: patched versions have been released

~~~~~~~~
Synopsis
~~~~~~~~~~~~~~~~~~~~~~~~

PHP version 4.3.9 is vulnerable to meta character attacks. The bug could
enable an attacker to read arbitrary files from the filesystem of a
webserver that hosts PHP scripts.

In addition PHP versions 4.3.6 until 4.3.9 as well as PHP versions 5.0.0
until 5.0.2 contain a bug that enables an attacker to manipulate the file
name of uploaded files to perform directory traversal.

While both vulnerabilities exist in windows and unix platform versions of
PHP, they can only be successfully exploited on windows systems.


~~~~~~~~
Vendor Status
~~~~~~~~~~~~~~~~~~~~~~~~

The vendor has been timely informed and has released patched versions of
the software (PHP 4.3.10/PHP 5.0.3). Those can be downloaded from
http://www.php.net


~~~~~~~~
Vulnerabilities
~~~~~~~~~~~~~~~~~~~~~~~~


addslashes() Vulnerability:
---------------------------

Scope:
PHP version 4.3.9 contains a bug in the function addslashes().
addslashes() can be used to sanitize userinput and render it thus
impossible for an attacker to influence scripts by injection meta
characters. In the default configuration, magic_quotes_gpc is set to "On"
which automagically performs addslashes() on every input value. However
because of a bug, the NULL byte is not correctly encoded by addslashes,
enabling an attacker to read arbitrary files from the file system, if user
input is used within include() or require() directives.

Details:
Addslashes should turn a NULL byte (will be written as %00 in this
advisory) into the string "\0" (backslash zero). In version 4.3.9 the
NULL byte is encoded as "\%00" (backslash null byte). Everything after
the NULL byte is ignored in include and require directives so that an
attacker can truncate the name of the file that is included in the PHP
script. The last character however will always be the backslash. As in
Windows the backslash is the path delimitor, this does not matter - the
file named before the backslash is still loaded.


Example:

Consider the following PHP script:

<?
$whatever = addslashes($_REQUEST['whatever']);
include("/path/to/program/" . $whatever . "/header.htm");
?>

A malicious attacker might open the following URL, disclosing the
boot.ini file:

http://localhost/phpscript.php?whatever=../../../../boot.ini%00

The trailing backslash from the escaped \%00 does for some reason not seem
to be of concern to include().



Upload Path Traversion Vulnerability:
-------------------------------------

Scope:
PHP automatically sanitizes the file name of uploaded files removing
everything before the last slash or backslash. This is done in order to
prevent path traversal attacks with uploaded files. However if an attacker
uploads a file containing a single quote and the attacked web server has
magic_quotes turned on (which is default configuration) or performs an
addslashes() directive on the name of the uploaded file, the quote is
prefixed with a backslash. This occurs after PHP checks for backslashes in
the filename. As the backslash is the path delimitor in windows, this
behavior enables an attacker to traverse the path by one directory level.

Example:
If a file with the name "..'file.ext" is uploaded, PHP turns the name to
"..\'file.ext" and the file is uploaded to the directory below of where
the PHP script copies it.


~~~~~~~~
Counter Measures
~~~~~~~~~~~~~~~~~~~~~~~~

Upgrade to PHP version 4.3.10, respectively 5.0.3.


~~~~~~~~
Timeline
~~~~~~~~~~~~~~~~~~~~~~~~

Oct. 08: Notified vendor of addslashes vulnerability
Oct. 14: Vendor reply
Nov. 02: Notified vendor of upload vulnerability
Nov. 04: Vendor reply
Nov. 20: Problems fixed in CVS
Dec. 14: Release of patched versions 4.3.10/5.0.3


EOF Daniel Fabian / @2004
d.fabian at sec-consult dot com

~~~~~~~~
Contact
~~~~~~~~~~~~~~~~~~~~~~~~

SEC Consult Unternehmensberatung GmbH

Büro Wien
Blindengasse 3
A-1080 Wien
Austria

Tel.: +43 / 1 / 409 0307 - 570
Fax.: +43 / 1 / 409 0307 - 590
Mail: office at sec-consult dot com
http://www.sec-consult.com

Date: Wed, 22 Dec 2004 19:40:46 +0100
From: Martin Schulze <joey@infodrom.org>
To: Stefan Esser <sesser@suspekt.org>
Cc: vendor-sec@lst.de, security@php.net
Subject: [vendor-sec] Re: PHP: Multiple vulnerabilities

Stefan Esser wrote:
> [08] TSRM/tsrm_virtual_cwd.c - virtual_popen() safe_mode_exec_dir bypass
> 
> When PHP is running multithreaded (f.e. multithreaded apache2, 
> roxen-zts, ...) popen() automaticly gets a "cd CURRENTDIR ; " prepended. 
> This happens directly before execution and after all checks. This means 
> a script could create a directory with shellcommands in its name and 
> execute them. Even if safe_mode_exec_dir is set to something like 
> "/wont/ever/execute/anything/because/this/dir/does/not/exist"
> 
>
http://cvs.php.net/diff.php/TSRM/tsrm_virtual_cwd.c?r1=1.41.2.7&r2=1.41.2.8&ty=h
> 
> Credits: Stefan Esser

I have a question about the referenced patch:

===================================================================
RCS file: /repository/TSRM/tsrm_virtual_cwd.c,v
retrieving revision 1.41.2.7
retrieving revision 1.41.2.8
diff -p --unified=3 -r1.41.2.7 -r1.41.2.8
--- tsrm_virtual_cwd.c  2004/12/02 00:44:33     1.41.2.7
+++ tsrm_virtual_cwd.c  2004/12/02 01:04:46     1.41.2.8
@@ -17,7 +17,7 @@
    +----------------------------------------------------------------------+
 */

-/* $Id: tsrm_virtual_cwd.c,v 1.41.2.7 2004/12/02 00:44:33 sesser Exp $ */
+/* $Id: tsrm_virtual_cwd.c,v 1.41.2.8 2004/12/02 01:04:46 sesser Exp $ */

 #include <sys/types.h>
 #include <sys/stat.h>
@@ -835,13 +835,24 @@ CWD_API FILE *virtual_popen(const char *
 CWD_API FILE *virtual_popen(const char *command, const char *type TSRMLS_DC)
 {
        int command_length;
+       int dir_length, extra = 0;
        char *command_line;
-       char *ptr;
+       char *ptr, *dir;
        FILE *retval;

        command_length = strlen(command);

-       ptr = command_line = (char *) malloc(command_length + sizeof("cd  ; ") +
CWDG(cwd).cwd_length+1);
+       dir_length = CWDG(cwd).cwd_length;
+       dir = CWDG(cwd).cwd;
+       while (dir_length > 0) {
+               if (*dir == '\'') extra+=3;
+               dir++;
+               dir_length--;
+       }
+       dir_length = CWDG(cwd).cwd_length;
+       dir = CWDG(cwd).cwd;
+
+       ptr = command_line = (char *) malloc(command_length + sizeof("cd '' ; ")
+ dir_length +1+1);
        if (!command_line) {
                return NULL;
        }
@@ -851,8 +862,21 @@ CWD_API FILE *virtual_popen(const char *
        if (CWDG(cwd).cwd_length == 0) {
                *ptr++ = DEFAULT_SLASH;
        } else {
-               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 */
+                       default:
+                               *ptr++ = *dir;
+                       }
+                       dir++;
+                       dir_length--;
+               }
+               *ptr++ = '\'';
        }

        *ptr++ = ' ';
The extra variable doesn't seem to be used except to count additional
space requirements.  It is not used afterwards, so there is either no
need to count additional string space, or there is "+ extra" missing
in the malloc command from above.  Hence, doesn't the above code write
over the end of the allocated area?

Regards,

       Joey

Date: Wed, 22 Dec 2004 20:01:10 +0100
From: Stefan Esser <sesser@php.net>
To: Martin Schulze <joey@infodrom.org>
Cc: Stefan Esser <sesser@suspekt.org>, vendor-sec@lst.de, security@php.net
Subject: [vendor-sec] Re: PHP: Multiple vulnerabilities

Ohhhhh....

> The extra variable doesn't seem to be used except to count additional
> space requirements.  It is not used afterwards, so there is either no
> need to count additional string space, or there is "+ extra" missing
> in the malloc command from above.  Hence, doesn't the above code write
> over the end of the allocated area?

It seems you are right. The situation that allowed arbitrary shell command
execution in the last version does now overflow the buffer.

Stefan

The patch from comment #17 was declared as non-security related by Joe Orton 
(comment #8) AFAICS. 

The never ending story continues *sigh*. I missed to post the mail here that 
explains the issues >[05] that are referred to in various other mails. Sorry 
Tomas :-( 
 
----8<---- 
more holes... 
 
[06] etx/standard/var_unserializer.c 
     etx/standard/var_unserializer.re - negative reference index array 
                                        underflow 
 
A negative index in a reference could leak to exploitable memory 
corruption. (NOTE: phpBB2 which is very famous uses unserialize on value 
of COOKIE, so this is remote exploitable) 
 
http://cvs.php.net/diff.php/php-src/ext/standard/var_unserializer.c?r1=1.18.4.11&r2=1.18.4.12&ty=h 
 
Credits: Stefan Esser 
 
[07] etx/standard/var_unserializer.c 
     etx/standard/var_unserializer.re - reference to already freed array 
                                        element 
 
A reference to an already freed zvalue can lead to my special friend: 
controlling a ZendHashTable incl. its destructor pointer. Due to the 
Zend Memory Cache it is easy to create a string that when unserialize is 
performed on it will result in cross platform jumping to a specifix EIP. 
(NOTE: phpBB2 is more or less easily exploitable with this, PoC exists) 
 
NO FIX IN CVS YET 
 
Credits: Stefan Esser 
 
[08] TSRM/tsrm_virtual_cwd.c - virtual_popen() safe_mode_exec_dir bypass 
 
When PHP is running multithreaded (f.e. multithreaded apache2, 
roxen-zts, ...) popen() automaticly gets a "cd CURRENTDIR ; " prepended. 
This happens directly before execution and after all checks. This means 
a script could create a directory with shellcommands in its name and 
execute them. Even if safe_mode_exec_dir is set to something like 
"/wont/ever/execute/anything/because/this/dir/does/not/exist" 
 
http://cvs.php.net/diff.php/TSRM/tsrm_virtual_cwd.c?r1=1.41.2.7&r2=1.41.2.8&ty=h 
 
Credits: Stefan Esser 
 
 
[09] TSRM/tsrm_virtual_cwd.c - virtual_file_ex() does not protect itself 
                               against malfunctional realpah() 
 
In some realpath() implementations (f.e. FreeBSD and OpenBSD (until a 
few days ago)) truncate the input string at MAXPATHLEN-1 bytes. This 
means if someone tries to do (with %00 properly escaped) 
 
include "modules/$modulname/bla.inc.php"; 
 
it is possible on these platforms to make $modulname very long so that 
realpath() automaticly cuts away the unwanted stuff in the end. 
 
http://cvs.php.net/diff.php/TSRM/tsrm_virtual_cwd.c?f=&r1=0&tr1=1.41.2.4&ty=h&r2=0&tr2=1.41.2.7 
 
Credits: Stefan Esser 
 
 
[10] main/safe_mode.c - Overlong filename fools security checks 
 
I already mailed vendor-sec in May about the mad differences in 
realpath() on all those systems. glibc allows f.e. 
"/etc/hosts/../passwd" and allows overlong input filenames. 
Combined with the fact that the safe_mode checks strlcpy()s the filename 
into a buffer of the length MAXPATHLEN it is possible to do something like 
 
include "$LONG_PATH_THAT_I_AM_ALLOWED_TO_INCLUDE/../../../../etc/passwd" 
 
safe_mode checks will say: okay you can include the file, because it's 
name is truncated before the /../ start and then later the complete path 
is taken for inclusion. 
 
http://cvs.php.net/diff.php/php-src/main/safe_mode.c?r1=1.51.2.4&r2=1.51.2.5&ty=h 
 
Credits: Stefan Esser 
---->8----- 
 
Additionally the patch for [07] seems to be missing. 
 
AFAICS we now have the following status in 9.2: 
 
[01] - included 
[02] - included 
[03] - included 
[04] - included 
[05] - missing, not affected 
[06] - missing 
[07] - missing 
[08] - missing, upstream patch possibly broken 
[09] - missing, upstream patch possibly broken 
[10] - missing 
[11] - included 
 
If we share the opinion of Joe Orton (do we? I can't judge) we need to fix 
[03], [06], [07] and [11]. The others are only exploitable by malicious 
scripts which however may be introduced by faulty php applications we do not 
ship ourselves fortunately. So if we don't patch the malicious script things, 
we need packages with [06] and [07]. 

Tomas, are you still with us? I hope you didn't get a heart attack!? ;-) 

Almost! For a lack of time, php4 has found a new maintainer - mcihar.

If I underastand that correctly, two things need to be fixed now:

[06] etx/standard/var_unserializer.c 
     etx/standard/var_unserializer.re - negative reference index array 
                                        underflow 
 
[07] etx/standard/var_unserializer.c 
     etx/standard/var_unserializer.re - reference to already freed array 
                                        element 

For [06] patch exists, while for [07] does not.

[10] seems to be quite simple patch so it could go also.

And what about [08] and [09], there was no fix in cvs for last month are they
really broken?

[07] see comment #9 

Created attachment 27493 [details]
discussion about the broken patch

Packages fixing [06], [07], [10] (and bug 64617) submitted.

<!-- SBZ_reopen -->Reopened by lnussel@suse.de at Tue Jan 11 17:58:30 2005, took initial reporter meissner@suse.de to cc

thanks! 

Michal, which subpackages are affected on 9.2? 

I thing that apache2-mod_php4 and php4.

packages and updates released 

CVE-2004-1064: CVSS v2 Base Score: 10.0 (AV:N/AC:L/Au:N/C:C/I:C/A:C)