|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #47828 Seg Fault in openssl_x509_parse
Submitted: 2009-03-29 16:02 UTC Modified: 2009-03-30 18:08 UTC
From: reinke at securityspace dot com Assigned: scottmac
Status: Closed Package: OpenSSL related
PHP Version: 5.2.9 OS: Linux (Debian Lenny)
Private report: No CVE-ID:
 [2009-03-29 16:02 UTC] reinke at securityspace dot com
A user calling openssl_x509_parse is able to induce a segfault
by passing in specific data. In this case, the data is a certificate
found on a public SSL site.

Command line version of PHP is used in latest Debian (Lenny),
php -v reports: (Contrary to your form - I'm guessing Lenny is
up to 5.2.9 with the patch line as shown below)

PHP 5.2.6-1+lenny2 with Suhosin-Patch (cli) (built: Jan 26 2009 22:41:04)

PHP script that reproduces the problem is included below.

This certificate is one of more than half a million.  Only this 
certificate caused the coredump.  Older (_much_ older - PHP 4.4.1)
version of PHP did not exhibit this problem.

In all fairness, it's not clear to me at this point that the problem
is in PHP - it's looking highly possible to be in the underlying libraries.

Reproduce code:
        $cert = str_replace("\\n", "\n", $certnl);
        $arr = openssl_x509_parse($cert);

Expected result:
Not see a segmentation fault.

Actual result:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb77946d0 (LWP 10516)]
0xb7985c1c in memcpy () from /lib/i686/cmov/
(gdb) bt
#0  0xb7985c1c in memcpy () from /lib/i686/cmov/
#1  0x082b7571 in _estrndup ()
#2  0x082d8245 in add_next_index_stringl ()
#3  0x0809d6d0 in ?? ()
#4  0x08fea7c0 in ?? ()
#5  0xb7f332e0 in ?? () from /lib/
#6  0xb77bab48 in ?? ()
#7  0x00000001 in ?? ()
#8  0x00000001 in ?? ()
#9  0xbfc385c4 in ?? ()
#10 0x08fea7c0 in ?? ()
#11 0x083587c3 in ?? ()
#12 0x08fe93b4 in ?? ()
#13 0x00000001 in ?? ()
#14 0xb78da3e8 in ?? () from /usr/lib/i686/cmov/
#15 0x0901e9a8 in ?? ()
#16 0x0901ee20 in ?? ()
#17 0xffffffff in ?? ()
#18 0x00000001 in ?? ()
#19 0xbfc38758 in ?? ()
#20 0xb7f332e0 in ?? () from /lib/
#21 0x0809d947 in zif_openssl_x509_parse ()
Backtrace stopped: frame did not save the PC


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-03-29 16:09 UTC]
Please try using our official releases, not the patched PHP from Debian. 

I will also test your csr later this week.
 [2009-03-29 17:20 UTC]
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.
 [2009-03-29 21:48 UTC] 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
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
(gdb) r core2.php
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb78088e0 (LWP 4011)]
0xb79dbb56 in memcpy () from /lib/tls/i686/cmov/
(gdb) bt
#0  0xb79dbb56 in memcpy () from /lib/tls/i686/cmov/
#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 ()

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, 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)
 [2009-03-29 21:50 UTC] reinke at securityspace dot com
Updated OS' impacted.
 [2009-03-29 21:51 UTC]
Thanks for testing all these distributions but it is not what I was asking.

Please use's sources, available in our downloads page, snapshots via cvs.

See my next comment for the snapshot links.
 [2009-03-29 21:51 UTC]
Please try using this CVS snapshot:
For Windows:

 [2009-03-29 22:29 UTC] 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 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

reproduces the problem.
 [2009-03-29 23:33 UTC]
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
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.
 [2009-03-29 23:38 UTC] reinke at securityspace dot com
Also reproduced on Lenny using snapshot php5.2-200903292230.

./configure --with-openssl
sapi/cli/php ~/core2.php
-> segmentation fault.
 [2009-03-29 23:45 UTC]
I fixed it about 10 minutes ago, the snapshot is from a few hours ago.
 [2009-03-30 05:52 UTC]
Scott, that's nice but add a test please with the data you use to reproduce the segfault.
 [2009-03-30 06:00 UTC]
"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 and, 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.
 [2009-03-30 09:24 UTC]
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

 [2009-03-30 09:59 UTC]
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.
 [2009-03-30 14:43 UTC] reinke at securityspace dot com
>>No, our official distributions channel is
and, 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.

 [2009-03-30 14:55 UTC]
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.
 [2009-03-30 18:08 UTC]
For the record here, if you use ubuntu you can follow this issue here:

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 :).
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Wed Apr 23 09:02:23 2014 UTC