Bug 1166264 - NTLM: ignore CURLOPT_FORBID_REUSE during NTLM HTTP auth [RHEL-7]
Summary: NTLM: ignore CURLOPT_FORBID_REUSE during NTLM HTTP auth [RHEL-7]
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: curl
Version: 7.2
Hardware: All
OS: Linux
high
low
Target Milestone: rc
: ---
Assignee: Kamil Dudka
QA Contact: Stefan Kremen
URL:
Whiteboard:
Depends On:
Blocks: 1154747
TreeView+ depends on / blocked
 
Reported: 2014-11-20 16:53 UTC by Kamil Dudka
Modified: 2015-11-19 07:07 UTC (History)
3 users (show)

Fixed In Version: curl-7.29.0-24.el7
Doc Type: Bug Fix
Doc Text:
libcurl provides a FORBID_REUSE flag to disable reuse of existing connections. However, the connection reuse feature is internally used to implement NTLM (NT LAN Manager) authentication. This resulted in authentication failures when the FORBID_REUSE was set. An upstream patch has been applied on libcurl sources to ensure that the FORBID_REUSE flag does not interfere with the NTLM authentication. Now both the features can be used together with no side effects.
Clone Of: 1154747
Environment:
Last Closed: 2015-11-19 07:07:19 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:2159 0 normal SHIPPED_LIVE Moderate: curl security, bug fix, and enhancement update 2015-11-19 08:26:18 UTC

Description Kamil Dudka 2014-11-20 16:53:28 UTC
+++ This bug was initially created as a clone of Bug #1154747 +++

Description of problem:
if CURLOPT_FORBID_REUSE is set, requests using NTLM failed
since NTLM requires multiple requests that re-use the same connection
for the authentication to work

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

How reproducible:
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.

Expected results:
Ignore the forbid reuse flag in case the NTLM authentication
handshake is in progress, according to the NTLM state flag.

Additional info:

Please refer to curl fix here.
https://github.com/bagder/curl/commit/63a0bd4270decef04e64fbe497b42f2c9e26c62b

--- Additional comment from Paul Ling on 2014-10-22 20:51:24 CEST ---

Steps to Reproduce:
1. Create curl multi handle with most default options, I only set CURLMOPT_SOCKETFUNCTION/CURLMOPT_SOCKETDATA for libevent integration
2. Create and add easy handle for NTLM authentication HTTPS request with AD user A credentials. One connection will be established this time
3. Create and add one HTTPS request to the same web server but doesn't require NTLM authentication afterward, libcurl will reuse the connection which send NTLM authentication request.
4. Create and add the third request as same as the first NTLM requests with the same user. libcurl still want to reuse the same connection for this new NTLM request. But IIS will return 401 always as below unless the old connection break down and new connection established.


 * Re-using existing connection! (#0) with host hhh.xxx.com
 * Connected to hhh.xxx.com (10.26.0.100) port 443 (#0)
 * Server auth using NTLM with user 'ppp'
 > POST /auth/useradauth HTTP/1.1^M
 User-Agent: libcurl/7.19.7 NSS/3.13.1.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2^M
 Host: hhh.xxx.com^M
 Accept: */*^M
 Content-Type: application/json^M
 Content-Length: 67^M
 ^M
 < HTTP/1.1 401 Unauthorized^M
 < Server: Microsoft-IIS/7.5^M
 * gss_init_sec_context() failed: : Credentials cache file '/tmp/krb5cc_0' not found< WWW-Authenticate: Negotiate^M
 * Authentication problem. Ignoring this.
 < WWW-Authenticate: NTLM^M
 < X-Powered-By: ASP.NET^M
 < Date: Wed, 22 Oct 2014 18:40:44 GMT^M
 < Content-Length: 0^M
 < ^M
 * Connection #0 to host hhh.xxx.com left intact

--- Additional comment from Paul Ling on 2014-10-24 23:19:20 CEST ---

Let me explain little bit more about my case.
My web server has two web apps, one is authenticator which takes IWA authentication and issue my special ticket to client. The second web app is that takes this ticket inside of HTTP body to provide discovery service, this web app does not request NTLM authentication.

The client process is that sending authentication HTTPS request with user/password to the first webapp, following by the second NON-NTLM HTTPS request without user/password. Once my client repeat this process, only the first authentication HTTPS request got succeeded, the second time authentication and later will always got 401 failure because of the connection re-use.

Comment 7 errata-xmlrpc 2015-11-19 07:07:19 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-2159.html


Note You need to log in before you can comment on or make changes to this bug.