Bug 141136 - CAN-2004-1018 Multiple issues in PHP (CAN-2004-1019 CAN-2004-1020)
CAN-2004-1018 Multiple issues in PHP (CAN-2004-1019 CAN-2004-1020)
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: php (Show other bugs)
4.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Joe Orton
David Lawrence
impact=important,public=20041215
: Security
: 144259 (view as bug list)
Depends On:
Blocks: 142822
  Show dependency treegraph
 
Reported: 2004-11-29 11:00 EST by Josh Bressers
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-15 04:23:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Josh Bressers 2004-11-29 11:00:02 EST
Stefan Esser reported these issues to vendor-sec.



[01] ext/shmop/shmop.c - shmop_write() out of bounds memory write access
CAN-2004-1018

http://cvs.php.net/diff.php/php-src/ext/shmop/shmop.c?r1=1.23.8.2&r2=1.23.8.3&ty=h

credits: Stefano Di Paola / WiSEC


[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 (Yes same as [01])

http://cvs.php.net/diff.php/php-src/ext/standard/pack.c?r1=1.53&r2=1.54&ty=h

credits: Stefan Esser


[03] etx/standard/var_unserializer.c
     etx/standard/var_unserializer.re - possible information
                                        leaks/overflows
CAN-2004-1019

http://cvs.php.net/diff.php/php-src/ext/standard/var_unserializer.re?r1=1.11.4.3&r2=1.11.4.4&ty=h
http://cvs.php.net/diff.php/php-src/ext/standard/var_unserializer.c?r1=1.18.4.8&r2=1.18.4.9&ty=h

credits: Marcus Boerger (later also reported by Sec-Consult)


[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. )

http://cvs.php.net/diff.php/php-src/main/rfc1867.c?r1=1.122.2.27&r2=1.122.2.28&ty=h

credits: Daniel Fabian / Sec-Consult


Only PHP 4.3.9 is affected (NOT PHP 5 or PHP < 4.3.9)
-----------------------------------------------------

[05] ext/standard/string.c - addslashes (and therefore
magic_quotes_gpc) does not properly escape \0
CAN-2004-1020

http://cvs.php.net/diff.php/php-src/ext/standard/string.c?r1=1.333.2.44&r2=1.333.2.45&ty=h

credits: Daniel Fabian / Sec-Consult



All issues but [05] should also affect FC2.

I'm marking this issue as security sensitive since the upstream
release announcing this fix.  We'll make this public when the rest of
the world knows about it.
Comment 4 Josh Bressers 2004-12-06 16:52:00 EST
Here are the additional issues.


[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)

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

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.


[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


[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
Comment 5 Josh Bressers 2004-12-06 16:54:30 EST
I forgot the CVE id's in my previous post.

= CAN-2004-1019
[06] etx/standard/var_unserializer.c
      etx/standard/var_unserializer.re - negative reference index array
                                         underflow

= CAN-2004-1019
[07] etx/standard/var_unserializer.c
      etx/standard/var_unserializer.re - reference to already freed array
                                         element

= CAN-2004-1063 (Arbitrary command execution)
[08] TSRM/tsrm_virtual_cwd.c - virtual_popen() safe_mode_exec_dir bypass

= CAN-2004-1064 (arbitrary file access through path truncation)
[09] TSRM/tsrm_virtual_cwd.c - virtual_file_ex() does not protect itself
                                against malfunctional realpah()

= CAN-2004-1064 (arbitrary file access through path truncation)
[10] main/safe_mode.c - Overlong filename fools security checks

= CAN-2004-1065 (Stack overflow)
[11] ext/exif/exif.c - exif_read_data() overflow on long sectionname
Comment 6 Joe Orton 2005-01-07 05:50:10 EST
*** Bug 144259 has been marked as a duplicate of this bug. ***
Comment 7 Mark J. Cox (Product Security) 2005-02-15 04:23:28 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2005-032.html

Note You need to log in before you can comment on or make changes to this bug.