#18863 [Fbk->NoF]: PHP leaves a SYSV semaphore unclosed (php -v). Denial of service possibility.

ID: 18863 Updated by: php-bugs@lists.php.net Reported By: bryce@redhat.com -Status: Feedback +Status: No Feedback Bug Type: Unknown/Other Function Operating System: RHAT Linux (i386 and Alpha) PHP Version: 4.1.2 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: ------------------------------------------------------------------------ [2002-10-10 06:47:53] wez@php.net Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip ------------------------------------------------------------------------ [2002-10-10 00:25:33] mrfloppy@ntrippy.net I have just compiled and tested this on RH7.2 ans 4.2.4-dev and the same behaviour still exists. If you run php -v enough times (in my case 58 times) you end up with a whole bunch of semaphore arrays that have not been cleaned up and php dying when run fit rom the command line with: $ php -v Content-type: text/html PHP Fatal error: Unable to start session mm module in Unknown on line 0 ------------------------------------------------------------------------ [2002-08-12 09:51:30] sander@php.net IIRC, this was fixed someday... if it works with 4.2.2 than it's no longer a bug. Please try a (non-STABLE) snapshot from http://snaps.php.net and reopen this report if the problem still persists. ------------------------------------------------------------------------ [2002-08-12 00:34:48] bryce@redhat.com I've been contacted by a php user in the wild who told me that by simply issuing 'php -v', a semaphore that php opens for session management is not closed on exit. This becomes bad news because the ipc system on linux is a global resource and not based per user, so it's possible for a local user to DOS the box by running php -v repeatidly. [test@alpha3 test]$ ipcs > l [test@alpha3 test]$ php -v Content-type: text/html 4.1.2 [test@alpha3 test]$ ipcs > ll [test@alpha3 test]$ diff l ll 9a10,11 > 0x00000000 65538 test 600 1 > 0x00000000 98307 test 600 1 I tried to trace this out between 4.1.2 and 4.2.2 (4.2.2 does not exhibit this behaviour) but I can find no obvious differances in the codepaths between versions. This behaviour seems to be present all the way back to 4.0.6 from the little additional checking I made. Please see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=71097 For a more detailed analysis The RH 4.1.2 configure incantation: ./configure --prefix=/usr --with-config-file-path=/etc --enable-force-cgi-redirect --disable-debug --enable-pic --disable-rpath --enable-inline-optimization --with-bz2 --with-db3 --with-curl --with-dom=/usr --with-exec-dir=/usr/bin --with-freetype-dir=/usr --with-png-dir=/usr --with-gd --enable-gd-native-ttf --with-ttf --with-gdbm --with-gettext --with-ncurses --with-gmp --with-iconv --with-jpeg-dir=/usr --with-mm --with-openssl --with-png --with-pspell --with-regex=system --with-xml --with-expat-dir=/usr --with-zlib --with-layout=GNU --enable-bcmath --enable-debugger --enable-exif --enable-ftp --enable-magic-quotes --enable-safe-mode --enable-sockets --enable-sysvsem --enable-sysvshm --enable-discard-path --enable-track-vars --enable-trans-sid --enable-yp --enable-wddx --without-oci8 --with-imap=shared --with-imap-ssl --with-kerberos=/usr/kerberos --with-ldap=shared --with-mysql=shared,/usr --with-pgsql=shared --with-snmp=shared,/usr --with-snmp=shared --enable-ucd-snmp-hack --with-unixODBC=shared --enable-memory-limit --enable-bcmath --enable-shmop --enable-versioning --enable-calendar --enable-dbx --enable-dio --enable-mbstring --enable-mbstr-enc-trans --enable-force-cgi-redirect Phil =--= ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=18863&edit=1