php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #69088 PHP_MINIT_FUNCTION does not fully initialize cURL on Win32
Submitted: 2015-02-20 12:14 UTC Modified: 2015-02-22 15:43 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: grant at digitaldj dot net Assigned: ab (profile)
Status: Closed Package: cURL related
PHP Version: 5.6.6 OS: Windows (all)
Private report: No CVE-ID: None
 [2015-02-20 12:14 UTC] grant at digitaldj dot net
Description:
------------
Since cURL 7.40.0, HTTP Digest Authentication support is now handled by Windows SSPI.

To initialize cURL, the php_curl module uses curl_global_init(CURL_GLOBAL_SSL); This call skips initializing any Win32 specific features (see curl_global_init in cURL lib/easy.c). 

As a result, the SSPI interface is not initialized and attempting to use HTTP Digest Authentication results in referencing a null pointer, s_pSecFn, in Curl_sasl_create_digest_http_message (lib/curl_sasl_sspi.c).

To fix, PHP_MINIT_FUNCTION should call curl_global_init with CURL_GLOBAL_DEFAULT. This will not affect non-Win32 platforms and is the cURL recommended default.

This was tested with the official Windows PHP binaries, 5.6.6 VC11 x86 Thread Safe, running on Windows 8.1 x64.



Test script:
---------------
<?php
$url = "http://httpbin.org/digest-auth/auth/user/passwd";
$userPass = "user:pass";
$curl = curl_init($url);
curl_setopt($curl, CURLOPT_VERBOSE, true);
curl_setopt($curl, CURLOPT_USERPWD, $userPass);
curl_setopt($curl, CURLOPT_HTTPAUTH, CURLAUTH_DIGEST);
$response = curl_exec($curl);
curl_close($curl);
?>

Expected result:
----------------
cURL successfully sends a request to the server and PHP exits with code 0.

Actual result:
--------------
PHP crahes with null pointer reference s_pSecFn, in Curl_sasl_create_digest_http_message (lib/curl_sasl_sspi.c)

Patches

php_curl-win32-initialize-sspi (last revision 2015-02-20 12:15 UTC by grant at digitaldj dot net)

Pull Requests

Pull requests:

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-02-21 17:35 UTC] ab@php.net
-Status: Open +Status: Feedback
 [2015-02-21 17:35 UTC] ab@php.net
@grant, thanks for the patch. I've a couple of questions.

- you say that won't affect any non windows platforms, however the code isn't #ifdef'ed ... so looks like it could affect other platforms. Refering to http://curl.haxx.se/libcurl/c/curl_global_init.html , you mean CURL_GLOBAL_DEFAULT will init both CURL_GLOBAL_SSL and win32
- i've checked the same on master, but got no crash there ... wondering if you could check that as well
- were it possible to add some test for this?

Thanks.
 [2015-02-22 05:26 UTC] grant at digitaldj dot net
Hi,

The code is in fact #ifdef'd. The code calls win32_init() but all code within that function is appropriately #ifdef'd (all of this is in cURL's lib/easy.c).

From a maintainability point of view, going with CURL_GLOBAL_DEFAULT is the best action. Even the curl binary on Linux initializes with CURL_GLOBAL_DEFAULT.

The alternative however, is to compile cURL without USE_WINDOWS_SSPI. This falls back to the Unix-method of manually parsing the HTTP Digest Challenge Message. The Windows SSPI code is then avoided and the behavior of cURL more closely matches that of when running on Unix platforms.

As for master, I'm not sure. I'm having a little trouble getting it to compile with what I have installed (VC12). But I'll give it my best shot. I've scoured the commits and I can't see anything that would affect it....unless of course you are compiling cURL without USE_WINDOWS_SSPI.

Cheers
 [2015-02-22 05:31 UTC] grant at digitaldj dot net
As for tests, the test script attached to the bug is the only decent way I can think of testing whether cURL is compiled with USE_WINDOWS_SSPI. Unfortunately, it relies on a remote server.
 [2015-02-22 11:42 UTC] ab@php.net
After looking at lib/easy.c - agreed, default is CURL_GLOBAL_SSL|CURL_GLOBAL_WIN32 and that's just one empty call which will be optimized away, so that's fine. I also think it makes sense to use SSPI. Still two things I'd ask you to do:

- it's probably safer to do curl version check on compile time, as it's unknown what possible differences older versions have
- please rebase the PR against 5.5 as we use curl 7.40.0 there, too. Or i can backport it later after merge, actually not a big deal (not sure it'll need to recreate a PR).

With master - probably other topic, but we still use VC11 for it. VC12 should work, however there are no deps prepared (like you could fetch for VC11 from windows.php.net), so you'll need to do that yourself. But in general - maybe you could report in some other ticket or on the mailing lists, what the exact issues you met are.

Thanks.
 [2015-02-22 13:11 UTC] grant at digitaldj dot net
Hi

I've created two more pull requests one against PHP-5.5 and another against PHP-5.6.

https://github.com/php/php-src/pull/1113
https://github.com/php/php-src/pull/1112
 [2015-02-22 15:43 UTC] ab@php.net
-Status: Feedback +Status: Closed -Assigned To: +Assigned To: ab
 [2015-02-22 15:43 UTC] ab@php.net
Merged.

Btw looked to some versions back in curl, it seems CURL_GLOBAL_ALL is used in most of the places and tests. So it should be fine with even older curl versions.

Thanks.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 08:01:29 2024 UTC