Bugzilla Bug 131135

the most important vuln reported would be this one. Our php-5.1.2 contains the
same sources.

PHP team, please confirm if we are vulnerable. In such case it's an "A1",
"critical".


i. PHP4/PHP5 wordwrap() buffer overflow

Function wordwrap() wraps a string to the given number of characters using a
string break character. There is a buffer overflow (heap) vulnerability in
the PHP wordwrap() caused by an integer miscalculation if long strings are
passed to the wordwrap() function. With a proper string size, it is
possible to allocate a small heap buffer that will be overflowed in the
memcpy() function. There are several different ways to make the overflow,
and one of them will be described here.

In [1] or [2], integer 'alloced' is calculated from user input (text and
breakchar) strings length. It is possible to set long strings (about 1 MB)
that will wrap around in multiplication and result in small positive integer
that will be used in [3] for memory allocation. In [4], user input is copied
to the newly allocated buffer 'newtext' that is too short, and will be
overflowed in memcpy(). Copy size 'current' will contain string length of
the user supplied string 'text'.

Vulnerable code php-4.4.2/ext/standard/string.c:
--------------------------------------------------------
PHP_FUNCTION(wordwrap)
{
        const char *text, *breakchar = "\n";
        char *newtext;
        int textlen, breakcharlen = 1, newtextlen, alloced, chk;
        long current = 0, laststart = 0, lastspace = 0;
        long linelength = 75;
        zend_bool docut = 0;
 ...
                if (linelength > 0) {
                        chk = (int)(textlen/linelength + 1);
[1] alloced = textlen + chk * breakcharlen + 1;
                } else {
                        chk = textlen;
[2] alloced = textlen * (breakcharlen + 1) + 1;
                }
                if (alloced <= 0) {
                        RETURN_FALSE;
                }
[3] newtext = emalloc(alloced);

 ...
                if (laststart != current) {
[4] memcpy(newtext+newtextlen, text+laststart,
current-laststart);
                        newtextlen += current - laststart;
         }
 ...
}
--------------------------------------------------------

If memory_limit value is high, it is also possible to cause memory DoS
attack.

Well, as (for now) we don't patch in any way string.c or our PHP releases for
this vulnerability, I'd say we are vulnerable.
The advisory speaks of three issues:

i. PHP4/PHP5 wordwrap() buffer overflow
Confirmed in PHP 5.1.2 too.
No upstream fix available yet afaics.

ii. PHP4/PHP5 array_fill() DoS condition
This appeared to me like the other bug where you just called a function inside
itself, so it got in an endless loop, consumed all memory available for it
(memory_limit) and dies... So not really critical, but it's really intersting
to try this out on a system with no memory_limit support in PHP ("memlimit" USE
off), it really sucks up 2GB of RAM in 1-2 seconds and renders your system
pretty unusable.
No upstream fix available yet afaics.

iii. PHP5 substr_compare() DoS condition
Upstream fix available.

So, we'll have to wait on upstream for the other two still, should be quickly
fixed, at least for PHP5 I hope, PHP4 may take longer (still no fix for the
phpinfo() XSS fex.), so we may have to push out a new 5.1.2 rev that fixes all
of those, and a new 4.4.2 rev that fixes the ones that are already fixed in the
4_4 branch...
Best regards, CHTEKK.

An application needs to use wordwrap to be vulnerable so B1.

PHP 5.1.3 has been released upstream which fixes these issues.

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

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

PHP 5.1.4 and PHP 4.4.2-r2 where just added to CVS, which fix all the mentioned
security issues known to us.

PHP4
wordwrap() buffer overflow
safe_mode copy() bypass
open_basedir tempname() bypass
html_entity_decode not binary safe
phpinfo() XSS

PHP5
wordwrap() buffer overflow
substr_compare() DoS
safe_mode copy() bypass
open_basedir tempname() bypass
html_entity_decode not binary safe
phpinfo() XSS

To the arch-teams: please stabilize dev-lang/php-4.4.2-r2 and
dev-lang/php-5.1.4, thanks!
Best regards, CHTEKK.

OK, then let's go and stabilize dev-lang/php-4.4.2-r2 and php-5.1.4

Arches, it's up to you.

Created an attachment (id=86202) [details]
patch for php-4.4.2-r2 zend-info

5.1.4 stable on amd64

4.4.2-r2:
/bin/sh /var/tmp/portage/php-4.4.2-r2/work/php-4.4.2/libtool --silent
--preserve-dup-deps --mode=compile
/var/tmp/portage/php-4.4.2-r2/work/php-4.4.2/meta_ccld  -Iext/standard/
-I/var/tmp/portage/php-4.4.2-r2/work/php-4.4.2/ext/standard/ -DPHP_ATOM_INC
-I/var/tmp/portage/php-4.4.2-r2/work/php-4.4.2/include
-I/var/tmp/portage/php-4.4.2-r2/work/php-4.4.2/main
-I/var/tmp/portage/php-4.4.2-r2/work/php-4.4.2 -I/usr/include/libxml2
-I/usr/X11R6/include -I/usr/include/freetype2
-I/var/tmp/portage/php-4.4.2-r2/work/php-4.4.2/ext/mbstring/mbregex
-I/var/tmp/portage/php-4.4.2-r2/work/php-4.4.2/ext/mbstring/libmbfl
-I/var/tmp/portage/php-4.4.2-r2/work/php-4.4.2/ext/mbstring/libmbfl/mbfl
-I/usr/include/mysql -I/usr/include/pspell
-I/var/tmp/portage/php-4.4.2-r2/work/php-4.4.2/TSRM
-I/var/tmp/portage/php-4.4.2-r2/work/php-4.4.2/Zend  -D_REENTRANT 
-march=athlon64 -O3 -pipe -fomit-frame-pointer -ffast-math -pthread -DZTS  -c
/var/tmp/portage/php-4.4.2-r2/work/php-4.4.2/ext/standard/iptc.c -o
ext/standard/iptc.o
/var/tmp/portage/php-4.4.2-r2/work/php-4.4.2/ext/standard/info.c: In function
`php_print_gpcse_array':
/var/tmp/portage/php-4.4.2-r2/work/php-4.4.2/ext/standard/info.c:158: error:
too many arguments to function `zend_print_zval_r'
make: *** [ext/standard/info.lo] Error 1
make: *** Waiting for unfinished jobs....

It fails in 4.4.2 because the zend api changes between versions, and someone
put in a function that relies on the zend api provided in php-5.1.4. Attached
is a patch that seems to fix it for me, but I don't know if it regresses any
security issues fixed by the version bump.

Actually, you don't need my patch. This is broken because of the following
patch:

4.4.2/php4.4.2-phpinfo_xss.patch

Please fix the phpinfo_xss.patch to call the zend_print_zval_r function
correctly for php-4.4.2-r2, then we can start marking it stable.

Uhhh sorry, that bug was already fixed yesterday when I tested those, and I
updated the patchset, at least the one on my mirror, but forgot to upload it to
the distfiles mirror. Now I've updated the patchset on the distfiles mirrors,
and will redigest the ebuilds, only dev-lang/php-4.4.2-r2 is affected by this,
sorry again.
Best regards, CHTEKK.

stable and tested amd64; I hope the distfiles mirrors sync soon ;)

The tests in dev-lang/php-5.1.4 didn't run. They says I need CLI sapi, and in
the install phase it says "Installing SAPI(s)  cli apache2" and "Installing CLI
SAPI" It this a bug, or am I doing something completely wrong?

Some output from emerge =dev-lang/php-5.1.4:

>>> Test phase [test]: dev-lang/php-5.1.4

Build complete.
(It is safe to ignore warnings about tempnam and tmpnam).

ERROR: Cannot run tests without CLI sapi.

>>> Install php-5.1.4 into /var/tmp/portage/php-5.1.4/image/ category dev-lang
Installing build environment:    
/var/tmp/portage/php-5.1.4/image//usr/lib/php5/lib/php/build/
Installing header files:         
/var/tmp/portage/php-5.1.4/image//usr/lib/php5/include/php/
Installing helper programs:      
/var/tmp/portage/php-5.1.4/image//usr/lib/php5/bin/
  program: phpize
  program: php-config
Installing man pages:            
/var/tmp/portage/php-5.1.4/image//usr/lib/php5/man/man1/
  page: phpize.1
  page: php-config.1
 * Setting extension_dir in php.ini
 * Securing fopen wrappers
 * Setting correct include_path
 *
 * Installing SAPI(s)  cli apache2
 *
 * Installing CLI SAPI


dev-lang/php-5.1.4  USE="apache2 berkdb calendar cli crypt ctype curl
curlwrappers ftp gdbm ipv6 ncurses nls pcre readline recode reflection session
sockets spell spl ssl threads truetype xml xmlreader zip zlib -apache -bcmath
-bzip2 -cdb -cgi -cjk -dbase -debug -discard-path -doc -exif -fastbuild
-flatfile -force-cgi-redirect -gd -gd-external -gmp -hardenedphp -hash
-hyperwave-api -iconv -imap -inifile -interbase -iodbc -kerberos -ldap -libedit
-mcve -memlimit -mhash -ming -msql -mssql -mysql -mysqli -odbc -pcntl -pdo
-pdo-external -pic -posix -postgres -qdbm -sapdb -sasl -sharedext -sharedmem
-simplexml -snmp -soap -sqlite -sysvipc -tidy -tokenizer -unicode -vm-goto
-vm-switch -wddx -xmlrpc -xmlwriter -xpm -xsl -yaz"


# emerge --info
Portage 2.1_pre10-r2 (default-linux/alpha/no-nptl/2.4, gcc-3.4.6,
glibc-2.3.6-r3, 2.4.32 alpha)
=================================================================
System uname: 2.4.32 alpha EV56
Gentoo Base System version 1.12.0_pre16
dev-lang/python:     2.3.5, 2.4.3
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r2
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.4.26-r1
ACCEPT_KEYWORDS="alpha ~alpha"
AUTOCLEAN="yes"
CBUILD="alpha-unknown-linux-gnu"
CFLAGS="-mieee -pipe -O2 -mcpu=ev56"
CHOST="alpha-unknown-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/lib/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config
/var/qmail/control"
CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/revdep-rebuild
/etc/terminfo /etc/texmf/web2c /etc/env.d"
CXXFLAGS="-mieee -pipe -O2 -mcpu=ev56"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig collision-protect distlocks metadata-transfer sandbox
sfperms strict test"
GENTOO_MIRRORS="http://gentoo.mirrored.ca/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage
/usr/portage/local/layman/java-experimental"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="alpha X aac aalib aim alsa apache2 artworkextra async audacious audiofile
bash-completion berkdb binfilter bitmap-fonts bittorrent bl bonjour c++ cairo
calendar cdinstall cdparanoia cdr cdrom chroot cli config_wizard cracklib crypt
cscope csv ctype cups curl curlwrappers cvs cvsgraph dhcp dillo dri editor eds
elf encode epiphany escreen esd ethereal extraicons extras ffmpeg fftw figlet
firefox flac ftp gdb gdbm gif glep gnome gnutls gpm grammar gsl gstreamer gtalk
gtk gtk2 gtkspell gvim gzip html icq id3 imlib ipv6 jabber javascript jpeg
justify ladspa lame libg++ libsexy libwww lite lj logrotate lua mad mapeditor
md5sum mikmod motif moznoirc moznomail moznoroaming mozsha1 mp3 mpeg mpeg2
mplayer msn msnextras music ncurses net nethack nls offensive ogg oggvorbis
opengl openssh openssl oscar oss pam pcre pdflib perl png python quicktime
quotes readline recode reflection reiserfs scp screen sdl session sftp skins
sndfile sockets sounds sox speech spell spl ssl subversion symlink syslog tcpd
threads truetype truetype-fonts type1-fonts userlocales vcd videos vim
vim-with-x vorbis wma wma123 xml xml2 xmlreader xmms xorg xv xvid yahoo zip
zlib elibc_glibc kernel_linux userland_GNU"
Unset:  ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL,
LDFLAGS, LINGUAS

We don't support (atm, it's planned sometimes, maybe...) the PHP tests, they
vary too much between releases and are not a real test, since I never saw a PHP
version where, _if_ they started, they too all worked, at least 5-6 fail. So
atm just emerge, if it compiles, installs, php -v/-i gives you the expected
output, and if you try to run some app like phpMyAdmin, or others, it works,
then it's ok. That's how it was done till now and will probably be done for a
long time yet. :)
Best regards, CHTEKK.

ppc stable

alpha stable.

x86 done

stable on ppc64

HPPA already stabled both, they probably just forgot to remove themselves from
this bug.
SPARC still needs to stable dev-lang/php-4.4.2-r2.
Best regards, CHTEKK.

php-4.4.2-r2 is the proud owner of a sexy SPARC keyword.  Congrats!

thank you weeve !  :)

php 4.4.2-r2 & 5.1.4 are stable on all supported arches

arm, ia64, s390, sh, x86-fbsd, feel free to mark stable when you want to.

GLSA 200605-08