[php-maint] Bug#780771: php5-curl: libcurl no more sends client certificate during mutual TLS authentication

[Arjan Wekking]

Hello,

We have experienced this bug as well, and can confirm it. I believe I have also found the cause and what could fix it.

I’ve dug a little deeper and found it to be caused by the patch for CVE-2015-1352. This patch also contains a change in the PHP5 curl extension which is not related to that CVE at all, and this change is causing this bug. I believe that this curl change is misapplied and should be taken out of this patch.

The source of this patch is from upstream PHP:

  http://git.php.net/?p=php-src.git;a=commit;h=124fb22a13fafa3648e4e15b4f207c7096d8155e

Note that this one commit it fixes *multiple* PHP bugs, of which the curl bug is not related to CVE-2015-1352 it seems:

  https://bugs.php.net/bug.php?id=68739 (curl CURLOPT_SHARE switch/case fall-though bug)
  https://bugs.php.net/bug.php?id=68740 (null-dereference in ereg ext)
  https://bugs.php.net/bug.php?id=68741 (null-dereference in pgsql ext)

It looks like the original commit is applied to the master branch of PHP, or at least a branch that is well beyond v5.4.x. The curl bug is in fact not even present in PHP 5.4.x, because that CURLOPT_SHARE option (and the code the commit changes) does not even exist in PHP 5.4.x.

This particular curl change, however, found it’s way to the wrong part of the v5.4.x curl code (I suspect that some patch tool trying to fuzzily match the patch to the code), and introduced a break statement where it should not be.

The result is that setting following curl options are now effectively no-ops:

  CURLOPT_COOKIEJAR
  CURLOPT_SSLCERT
  CURLOPT_RANDOM_FILE
  CURLOPT_COOKIEFILE

In other words: setting CURLOPT_SSLCERT silently fails because the curl extension prematurely aborts the setting of that option, and thus no client certificate is given to the curl library. This also explains why the bug only occurs in the PHP curl extension and not when using curl on the command line (or from any other interface).

So, setting the CURLOPT_RANDOM_FILE option silently fails as well. When it is not set, curl will fall back to whatever it uses for a random file by default. I can imagine that someone uses this option because the default source of random data for curl is in fact unsafe, which makes the silent failure of setting this option arguably even worse.

To fix this, the broken CVE-2014-1352 patch should be replaced by one that does not make any changes to the curl extension, because it is not related to that security issue at all and is broken for v5.4.x anyway.

-Arjan