ID: 47828 Updated by: scott...@php.net Reported By: reinke at securityspace dot com -Status: Open +Status: Closed Bug Type: OpenSSL related Operating System: Linux (Debian Lenny) PHP Version: 5.2.9 Assigned To: pajoye New Comment:
This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. The string tried to decode one of the items to utf-8 and it failed, this wasn't properly checked resulting in a segfault. Previous Comments: ------------------------------------------------------------------------ [2009-03-29 22:29:26] reinke at securityspace dot com With all due respect - we are using PHP's official release. On Debian. As provided by the distro. On Ubuntu. As provided by Ubuntu. On Fedora. As provided by... well, you get it. Like it or not, these vendors are your distribution channel, and what they provide IS defacto your official release. Simply by virtue of the fact that most people are using that channel for getting their binary version of PHP. If you are asking us to help TEST the bug, fine - that's not a problem. If you are suggesting what I think you suggested, that is upgrading to your "official off the www.php.net web site" release to solve the problem, that's not happening, for a large variety of reasons. Nor will it happen for a LOT of other users, either. FWIW - on a Fedora Core 10 system, fully updated, your snapshot (php5.2-200903292030) configured and compiled with ./configure --with-openssl make reproduces the problem. ------------------------------------------------------------------------ [2009-03-29 21:51:18] paj...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ ------------------------------------------------------------------------ [2009-03-29 21:51:04] paj...@php.net Thanks for testing all these distributions but it is not what I was asking. Please use PHP.net's sources, available in our downloads page, snapshots via cvs. See my next comment for the snapshot links. ------------------------------------------------------------------------ [2009-03-29 21:50:43] reinke at securityspace dot com Updated OS' impacted. ------------------------------------------------------------------------ [2009-03-29 21:48:55] reinke at securityspace dot com Further testing has confirmed this is reproducible on a variety of Linux distributions. Some of these have been tested with virgin (installed from ISOs, but no updates applied) configurations, some with fully up to date (all updates applied). Confirmed as reproducible: Distro PHP version ------------------------------------------------------------- Debian 5.0 5.2.6-1+lenny2 Ubuntu 8.10 PHP 5.2.6-2ubuntu4.1 with Suhosin-Patch 0.9.6.2 Fedora Core 10 PHP 5.2.6 Slackware 12.1 PHP 5.2.5 Gentoo PHP 5.2.6-r7 (old version), 5.2.8-r2 (up to date) Debian 5.0 systems are fully up to date. Ubuntu 8.10 tested 2 setups, both seg faulted. - Setup 1: Latest PHP, ISO version of OpenSSL - Setup 2: Fully updated system Fedora Core 10 - tested both on virgin setup as well as fully up to date systems. Both setups segfaulted. Slackware - only virgin setup tested. Gentoo - 5.2.6-r7 - known out of date. 5.2.8-r2 involved a sync and rebuild of openssl and php along with a few other packages. Both seg faulted. On vulnerable systems, running "openssl x509 -inform PEM -in badcert.pem -text" where the signed pub key provided earlier is in "badcert.pem" (with \n markers appropriately changed to newline) spits out all information in the cert without any apparent problems. The Unbutu 8.10 gdb backtrace is typical of of the systems we tested (we stopped checking backtraces after Deb, Ubuntu, FC10 all produced the same thing) # gdb php <snip> (gdb) r core2.php <snip> Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb78088e0 (LWP 4011)] 0xb79dbb56 in memcpy () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb79dbb56 in memcpy () from /lib/tls/i686/cmov/libc.so.6 #1 0xffffffff in ?? () #2 0x082dea85 in add_next_index_stringl () #3 0x0809df90 in ?? () #4 0x0809e23a in zif_openssl_x509_parse () #5 0x08313f23 in ?? () #6 0x082ff3bb in execute () <snip> If you really think our SSL packages were out of date, we can provide that info. But we're pretty sure that in situations where we said we're fully up to date, that we were. We're aware we could install PHP from sources directly from php.net, but for maintenance reasons _really_ want to use the distro's packages. ALL of the above testing was using the distro's prepackaged software. We could NOT reproduce this on: CentOS 5.1 (php 5.1.6-20.el5_2.1) RedHat 5.2 (php 5.1.6-20.el5) ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/47828 -- Edit this bug report at http://bugs.php.net/?id=47828&edit=1