Please try using our official releases, not the patched PHP from Debian. 

I will also test your csr later this week.

Can't reproduce on Ubuntu 8.10, windows or latest debian (using PHP sources).

I would suggest to first see if you have the latest openssl (openssl debian's package contains the latest fixes) install.

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)

Updated OS' impacted.

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.

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

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.

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.

Also reproduced on Lenny using snapshot php5.2-200903292230.

./configure --with-openssl
make
sapi/cli/php ~/core2.php
-> segmentation fault.

I fixed it about 10 minutes ago, the snapshot is from a few hours ago.

Scott, that's nice but add a test please with the data you use to reproduce the segfault.

"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"

No, our official distributions channel is http://www.php.net/downloads and http://windows.php.net, nothing else.

Distributions, in their majority, do a great job at distributing php but they are not our official releases channel, especially not when they use unofficial patches like suhosin or other random changes.

The reason we ask to try PHP's version is to be sure about the src of the problem, we have no control over what the distros do or don't.

Pierre using the test given by the reporter I could reproduce this, took less than a minute to find the issue.

Assigning yourself a bug that you'll look at next week isn't all that useful, especially if someone with more time comes along in that next week. Perhaps we need to add multiple assignment to bugs?

FYI OpenSSL verions
OpenSSL 0.9.7l 28 Sep 2006 (OS X default)
OpenSSL 0.9.8j 07 Jan 2009

Firt, I do not care if it took 0.5 second or 3 hours.

Secondly, the bug is less than a day old, we did run test and it did not crash on all platforms I can test (windows, ubuntu x64/x86 and debian). So not it was not obvious that there was a real bug in the current code.

And finally, you can't know if a) there is already a patch or a fix and b) what's the status, simply because you did not bother to ask.

There is no problem to take over any bug as long as you simply ask before. It will save us time and pains (as in this kind of discussions, which happen only with you).

Thanks for your understanding and your work.

>>No, our official distributions channel is http://www.php.net/downloads
and http://windows.php.net, nothing else.

Pierre - that's wishful thinking and a pile of crock.
Argue over the semantics of "official" however you 
wish. The reality, however, is that about 28% of
all web sites with PHP are known to be using a
Distro version of PHP.  And of the remaining 72%,
we can't even say they are using a version from
your web site, only that we don't know if they are
using your version, or one from a distro.

Don't get me wrong - your (PHP's) fix time on this was 
absolutely amazing, and to repeat, we have no issue with 
helping out on a problem.  But telling folks not to use a
distro version of PHP is just not in line with reality.

And for the record - every 5.2.x install we've
touched on a Linux box was vulnerable.  If you
couldn't reproduce on Ubuntu or Debian using
the concise 3 line script provided after several
hours of our digging to make it easy on you, perhaps
you need to have a broader range of hardware to
check on. Every x86 based install WE checked on
5.2.x was vulnerable and reproduced the problem.
INCLUDING your latest snapshot.

Grumble - you ought to take this thread and mark it as a
"how to take a customer that was willing to help find
a bug that crashes your application and really piss
him off."

Scott - thanks for the quick fix. Above and beyond.

Thomas

Note that even people from Ubuntu security were not able to reproduce it (I asked them to take a look at the report). So excuse me but there were doubts about this bug, like it or not. And that's why I asked you to test with our src, you did, thanks.

Also I did not ask you to do not use the distribution version of php but to use our sources to see if the bug can be reproduced. It is common practice to ask that, not only in php.

For the record here, if you use ubuntu you can follow this issue here:

https://bugs.launchpad.net/bugs/351730

I also updated the test case using the one from Kees Cook as it covers more architectures (incl. the intel ones I have here, and that's nice :).

I have this segfault error with this cert:

-----BEGIN CERTIFICATE-----
MIIFJjCCBA6gAwIBAgIHKAOS9pUMTDANBgkqhkiG9w0BAQsFADCBtDELMAkGA1UE
BhMCVVMxEDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxGjAY
BgNVBAoTEUdvRGFkZHkuY29tLCBJbmMuMS0wKwYDVQQLEyRodHRwOi8vY2VydHMu
Z29kYWRkeS5jb20vcmVwb3NpdG9yeS8xMzAxBgNVBAMTKkdvIERhZGR5IFNlY3Vy
ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkgLSBHMjAeFw0xNDEyMDYwMDEzMThaFw0x
NzEyMTUyMDExMjFaMD0xITAfBgNVBAsTGERvbWFpbiBDb250cm9sIFZhbGlkYXRl
ZDEYMBYGA1UEAwwPKi53b3JkcHJlc3Mub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAt+6frTJfO3cL1/bxm02IFZB4koTgTnfwmqPPJRHZvwAUEiC9
lqZv2lPnxQtAjKZEei9TTFSQRLIih50CAZNT8ce6GruNTY95vLLJAHF4Csi6m5OZ
fx6Yk/lmzsRlAwdT85GLnl4jcgH0uU/bZTwz1MlCaxdDcVu2zAK1PnLj+wcELwGP
ifqtLnYVShlLPza295UvTOaVmp+VYcWvSwLtn+OiqXd405PWo3M13Yoh5/PyHajH
dBdDWhA4hrPvHvjbfKx5zcp/buoY3dRLHoOH+nE0k3QXraEDTY2MzOdMDKQriqhR
r82GswENojt35M4z7MA9KR1FwoSUdGbaiqGw9QIDAQABo4IBsTCCAa0wDAYDVR0T
AQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDgYDVR0PAQH/
BAQDAgWgMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuZ29kYWRkeS5jb20v
Z2RpZzJzMS04Ny5jcmwwUwYDVR0gBEwwSjBIBgtghkgBhv1tAQcXATA5MDcGCCsG
AQUFBwIBFitodHRwOi8vY2VydGlmaWNhdGVzLmdvZGFkZHkuY29tL3JlcG9zaXRv
cnkvMHYGCCsGAQUFBwEBBGowaDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZ29k
YWRkeS5jb20vMEAGCCsGAQUFBzAChjRodHRwOi8vY2VydGlmaWNhdGVzLmdvZGFk
ZHkuY29tL3JlcG9zaXRvcnkvZ2RpZzIuY3J0MB8GA1UdIwQYMBaAFEDCvSeOzDSD
MKIz1/tss/C0LIDOMCkGA1UdEQQiMCCCDyoud29yZHByZXNzLm9yZ4INd29yZHBy
ZXNzLm9yZzAdBgNVHQ4EFgQUTqA0/Tj3XxNMtsLjOsC9Kp8eLVgwDQYJKoZIhvcN
AQELBQADggEBACCua5vWQNfTc5aWJu80e6svEmQ7nTv8BeR1jWCUEgPz3EZqRE/P
64lZD+hjU+6sf3KLTqiwvdMef43kcpAHp7w4rUQm0NbW4RP5BcRIjdihfjjLLEfu
sT7KzKWPeb6msjEunKlzEZa9uvmFUz3zCWu9Z0p7QCaudGz9ldJxoOiPxXK2R5qd
T5AJvhH7+WpuxF6RXbjzpkcXOWB2gcidTI/Bw59a90X/ZoJJyaTT2iXP8cYECtwn
Mxo4/P3vJYtE3QFnev7zP+o5CT0gzCmjb9sLOvZE5fRxm+PEefyaFHMebNCElGtC
ZpM3tyeiqyIQK61TeTTSusxnCFjXIDa0tjQ=
-----END CERTIFICATE-----

Just save it in a file (f.ex. test.pem) and call this php code:

<?php
$ssl = openssl_x509_parse(file_get_contents('test.pem'));
print_r($ssl);
?>

Error in the Apache log file is:
[core:notice] [pid 16919] AH00052: child pid 16925 exit signal Segmentation fault (11)

No further debug information availavle, although "LogLevel debug"