Bugs item #2873666, was opened at 2009-10-06 21:42
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=2873666&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libcurl
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Dennis (jdennis-redhat)
Assigned to: Daniel Stenberg (bagder)
Summary: gss negotiate infinite loop if credentials invalid

Initial Comment:
using libcurl 7.19.6 in conjunction with xmlrpc-c 1.16.3

If the server usses Kerberos via gss negotiate and valid credentials cannot be
obtained for the user then libcurl enters an infinite loop and never returns.
(As a side note the HTTP method when this problem was observed was POST)

The problem manifests itself when negotiate auth is picked, but we cannot
successfully obtian the user's credentials with
gss_init_sec_context(). Curl_input_negotiate() correctly detects the failure and
returns -1. However Curl_http_input_auth does not do anything when
Curl_input_negotiate() returns an error, this seems to be the crux of the
problem. I believe it should set the flag data->state.authproblem = TRUE when
Curl_input_negotiate() fails. Failure to set the authproblem flag causes the
infinite loop thusly:

    output_auth_headers() is invoked, authstatus->picked ==
    CURLAUTH_GSSNEGOTIATE, however negdata->context is NULL (because
    gss_init_sec_context() failed in Curl_input_negotiate()) Thus
    output_auth_headers() never adds the negotiate response to the output header
    nor does it update any state.

    multi_runsingle sees newurl and Curl_follow indicates it should loop again.

    When it loops again Curl_http_auth_act() checks the data->state.authproblem
    flag which is false, so it sets newurl believing we need another round of
    challenge/response.

    The request is emitted (without any auth headers because
    Curl_input_negotiate() previously failed) and the server responds with a 401
    response indicating negotiate should be used. At this point the loop repeats
    itself.

If Curl_http_input_auth() had set the authproblem flag to true when
Curl_input_negotiate() failed then Curl_http_auth_act() would have detected the
problem and the newurl would not have been set and thus the loop would
terminate.

Attached is a patch which seems to solve the problem and to the best of my
knowledge does not adversly affect any other authentication logic in libcurl
(based on a careful examination of the program logic).

----------------------------------------------------------------------

>Comment By: Daniel Stenberg (bagder)
Date: 2009-10-14 04:51

Message:
The GSS code is not properly tested since it's not tested by our test suite
and I personally have nothing that uses GSS so I've never even used it. I
think your patch seems like a wise approach so if this makes proper auth
still work and bad auth bail out, I'll apply it to the source code once I
get back from my vacation in a few days.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=2873666&group_id=976
Received on 2009-10-14