Bug 141136

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

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

*** Bug 144259 has been marked as a duplicate of this bug. ***

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