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

[Ondřej Surý]

Arjan,

thank you very much for this analysis, and sorry for the breakage of
curl.

I am just preparing 5.4.39 update, so your email came just in time!

Cheers,
Ondrej

On Fri, Mar 20, 2015, at 12:27, Arjan Wekking wrote:
> 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
> _______________________________________________
> pkg-php-maint mailing list
> pkg-php-maint at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint


-- 
Ondřej Surý <ondrej at sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server