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 0x 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
