Bug 799557

Summary: RHEL-6 libcurl fails when using digest auth and have multiple auth options
Product: Red Hat Enterprise Linux 6 Reporter: Peter Edwards <thatsafunnyname>
Component: curlAssignee: Kamil Dudka <kdudka>
Status: CLOSED CURRENTRELEASE QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: medium Docs Contact:
Priority: high    
Version: 6.2CC: btotty, chorn, fkrska, gnaik, jasonmc, jkurik, johnny, jpittman, jtrowbri, juanino, kdudka, lingsubscribe, maxim, msaxena, nparmar, ovasik, prc, qe-baseos-security, ruben, sgaikwad, srandhaw, vanhoof
Target Milestone: rcKeywords: Patch, ZStream
Target Release: 6.5   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: curl-7.19.7-39.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-10-22 07:15:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 994246, 1096797    
Attachments:
Description Flags
backport of upstream 4851daf none

Description Peter Edwards 2012-03-03 00:12:58 UTC
Description of problem:
 
Using curl-7.19.7-26.el6_1.2.x86_64
 
curl -v --digest -u AliBaba:OpenSesame  'http://treasure.cave:80/door'
* About to connect() to treasure.cave port 80 (#0)
*   Trying 1.2.3.4... connected
* Connected to treasure.cave (1.2.3.4) port 80 (#0)
* Server auth using Digest with user 'AliBaba'
> GET /door HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.12.9.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2
> Host: treasure.cave
> Accept: */*
>
< HTTP/1.1 401 Access Denied
< Server: Microsoft-IIS/7.5
< WWW-Authenticate: NTLM
* gss_init_sec_context() failed: : Credentials cache file '/tmp/krb5cc_273' not foundWWW-Authenticate: Negotiate
< WWW-Authenticate: Digest realm="treasure.cave", nonce="My8yLzIwMTIgNjo1ODo0OSBQTQ", opaque="0000000000000000", stale=false, algorithm=MD5, qop="auth"
* gss_init_sec_context() failed: : Credentials cache file '/tmp/krb5cc_273' not foundWWW-Authenticate: Negotiate
< WWW-Authenticate: NTLM
< X-IS-Server: a_windows_host
< X-Powered-By: ASP.NET
< Date: Fri, 02 Mar 2012 23:57:48 GMT
< Content-Length: 17
<
* Connection #0 to host treasure.cave left intact
* Closing connection #0
401 Access Denied

Version-Release number of selected component (if applicable):

curl-7.19.7-26.el6_1.2.x86_64

How reproducible:

See above.
  
Actual results:

gss_init_sec_context() errors, 401 Access Denied.

Expected results:

No gss_init_sec_context() errors, no 401 Access Denied.

Additional info:
 
The same bug exists in curl 7.22.0 when configured with "--with-gssapi" , but is fixed in 7.23.0 and 7.24.0.  The bug is only present if curl is configured with "--with-gssapi".  
 
Line 738 of lib/http.c that was added in 7.23.0 is needed.  It is line 736 in an unpatched 7.19.7.  This line (along with a close brace):
 
if(authp->picked == CURLAUTH_GSSNEGOTIATE) {
 
Above and around:
 
if(data->state.negotiate.state == GSS_AUTHSENT) {

Fixes it.  Thanks.

Comment 1 Peter Edwards 2012-03-04 15:08:07 UTC
This was the commit that introduced the line above:
  https://github.com/bagder/curl/commit/4851dafcf164bf2de5bd33c3cf2b786422ed05b6
The mailing list bug report:
  http://curl.haxx.se/mail/lib-2011-10/0323.html
Thanks.

Comment 2 Kamil Dudka 2012-03-05 12:28:14 UTC
Thanks for the bug report and pointer to the upstream fix.  Please clarify what you mean by "regression in curl-7.19.7-26.el6_1.2.x86_64".  Do you mean that it worked in RHEL-6 before the update?  That sounds pretty unlikely to me...

Comment 3 Kamil Dudka 2012-03-05 12:32:11 UTC
Created attachment 567588 [details]
backport of upstream 4851daf

Comment 4 Peter Edwards 2012-03-05 12:44:40 UTC
Sorry.  It worked on RHEL-5.  I didn't test older RH RPM versions on RHEL-6.  I will do that now.

Comment 5 Peter Edwards 2012-03-05 14:22:13 UTC
I tested with:

curl-7.19.7-16.el6.x86_64
libcurl-7.19.7-16.el6.x86_64

libcurl-7.19.7-15.el6.x86_64
curl-7.19.7-15.el6.x86_64

libcurl-7.19.7-6.el6.x86_64
curl-7.19.7-6.el6.x86_64

it does not work with any of these, failing in the same manner.  It does work on RHEL-5 with:

curl-7.15.5-9.el5_7.4

Thanks for the quick response.

Comment 6 Kamil Dudka 2012-03-13 15:27:46 UTC
The bug was present also in Fedora 16.  I have submitted an update for it:

https://admin.fedoraproject.org/updates/curl-7.21.7-7.fc16

Comment 14 Kamil Dudka 2013-04-20 08:47:31 UTC
*** Bug 953864 has been marked as a duplicate of this bug. ***

Comment 15 Jason McCormick 2013-06-04 02:57:26 UTC
We've recently been working on a system upgrade from EL5 to EL6 and encountered this broken behavior with curl for NTLM authentication. I've repackaged the EL6 curl using the patch provided here and it solves are problem as well. Will this bug definitely be fixed in RHEL 6.5?

Comment 16 Kamil Dudka 2013-06-04 11:58:54 UTC
Thank you for confirming the fix, Jason!

If you want to increase the chance of having the fix for the issue included in RHEL 6.5, please contact the product support.  Bugzilla is only a bug tracking tool and RHEL updates are driven by customer requests.

Comment 17 Jason McCormick 2013-06-07 15:12:22 UTC
I've opened case #00886699 for this.

Comment 18 Peter Edwards 2013-06-07 15:29:44 UTC
Thank you Jason McCormick for opening the case.

Comment 32 Maxim Burgerhout 2013-09-26 07:12:19 UTC
Opened another case (#00949737) to emphasize that this is important for multiple customers.

Comment 37 RHEL Program Management 2013-10-14 00:47:16 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

Comment 38 Jason McCormick 2013-10-14 13:32:00 UTC
I've requested management escalation for this BZ and my case. I also can't find the reference KB article on the support site.

Comment 39 Kamil Dudka 2013-10-14 14:10:00 UTC
(In reply to Jason McCormick from comment #38)
> I also can't find the reference KB article on the support site.

There is a reference to Knowledge Base above on this page, it points to:

    https://access.redhat.com/site/solutions/325133

Comment 40 Jason McCormick 2013-10-14 14:30:47 UTC
I see that as "Access Denied". The URL says "If this is knowledge content, it may be unpublished or retired."

Comment 41 Christian Horn 2013-10-14 14:42:12 UTC
(In reply to Kamil Dudka from comment #39)
>     https://access.redhat.com/site/solutions/325133
This kbase contains no additional information.  It has been published just now, it can atleast help to guide affected users to this bz here.

@engineering: could we get a new test build including the patch?  Are we ok with handing it out for verification?  The new build will then probably be 6.5 based.

Comment 50 Christian Horn 2013-10-14 15:59:02 UTC
A new build of test packages has been initiated.  Please open a case with the Red Hat Support (i.e. open a case via access.redhat.com ) and hint at this bugzilla, you can then get the packages - to verify the patch works.

Comment 52 Christian Horn 2013-11-05 13:13:40 UTC
The following 2 testpackages have been verified by my customer to fix the issue.
  curl-7.19.7-37.1.el6.x86_64.rpm / 
  libcurl-7.19.7-37.1.el6.x86_64.rpm

Comment 63 Johnny Hughes 2014-10-10 09:30:39 UTC
I don't know if this is related, but on the CentOS Devel mail list, this patch was pointed out as needed to solve an issue for NTLM as well:

https://github.com/bagder/curl/commit/63a0bd4270decef04e64fbe497b42f2c9e26c62b

From this post:

http://lists.centos.org/pipermail/centos-devel/2014-October/012111.html

Comment 64 Kamil Dudka 2014-10-10 09:51:29 UTC
(In reply to Johnny Hughes from comment #63)
> https://github.com/bagder/curl/commit/63a0bd4270decef04e64fbe497b42f2c9e26c62b

The above takes effect only if you explicitly set CURLOPT_FORBID_REUSE.  I would not classify the patch as related to this bug.  There were dozens of other NTLM fixes in curl between 4851dafc and 63a0bd42.

Comment 65 Paul Ling 2014-10-10 22:43:41 UTC
(In reply to Kamil Dudka from comment #64)
> (In reply to Johnny Hughes from comment #63)

I am the person that post that thread (http://lists.centos.org/pipermail/centos-devel/2014-October/012111.html) to centOS developer mail list. I know that is not the same issue, but that issue (ignore CURLOPT_FORBID_REUSE during NTLM HTTP auth) bothers me more than this.

The connection of NTLM authenticated request shouldn't be reuse in libcurl multi interface because it includes authentication context, after reuse with other plain requests to the same server, the context will be messed up and then next request with the same user's NTLM authentication will get 401 always until this connection get closed by HTTP server, and new connection to be established for the NTLM request. 

But because of this defect, I couldn't set CURLOPT_FORBID_REUSE for NTLM authenticated request (it always failed after retry five times), due to NTLM requires the same connection for at least two continuous requests to finish authentication. This issue normally may not be able reproduce with curl command line because curl doesn't use the multi interface for asynchronous I/O that my appserver did.

That is a serious defect, I hope this issue can be patched to redhat 6 and CentOS 6 ASAP!

Paul Ling

Comment 66 Kamil Dudka 2014-10-13 07:07:13 UTC
(In reply to Paul Ling from comment #65)
> That is a serious defect, I hope this issue can be patched to redhat 6 and
> CentOS 6 ASAP!

While we appreciate your feedback, such a discussion makes no sense on a bug that is already fixed (and verified to be fixed).

Please file a separate bug, or better a customer case, for your issue.