Fix memory leak in curl_sasl.c

[neex]

If any parameter in a HTTP DIGEST challenge message is present multiple
times, memory allocated for all but the last entry should be freed.

Server answer to reproduce the leak is:

HTTP/1.1 401 hui
WWW-Authenticate: Digest algorithm=MD5, algorithm=MD5, nonce=1, nonce=2

Two blocks will be "definitely lost" in valgrind: one for the first algorithm and one for the first nonce.

[jay]

I'm ok with this but I think that's a really weird thing to see especially if they have the same algorithm. What server are you seeing that on? It says this for algorithm in RFC 2617:

If the algorithm is not understood, the challenge should be ignored (and a different one used, if there is more than one).

I would expect a different Digest challenge is somehow separated though and prefixed with 'Digest'. Even if it is it would appear we ignore duplicate digest messages see https://github.com/curl/curl/blob/curl-7_47_1/lib/http.c#L850-L872

[jay]

I'm ok with this but I think that's a really weird thing to see especially if they have the same algorithm. What server are you seeing that on? It says this for algorithm in RFC 2617:

If the algorithm is not understood, the challenge should be ignored (and a different one used, if there is more than one).

I would expect a different Digest challenge is somehow separated though and prefixed with 'Digest'. Even if it is it would appear we ignore duplicate digest messages see https://github.com/curl/curl/blob/curl-7_47_1/lib/http.c#L850-L872

[dfandrich]

I was able to verify the problem and checked in test 1437 which shows it.

[dfandrich]

I was able to verify the problem and checked in test 1437 which shows it.

[neex]

The snippet in the first comment is just most simple testcase which I prepared to demonstrate the issue. The original server response (obtained by fuzzing) doesn't make any sense for me too (in fact, it was more erroneous as it had invalid algorithm field).

[neex]

The snippet in the first comment is just most simple testcase which I prepared to demonstrate the issue. The original server response (obtained by fuzzing) doesn't make any sense for me too (in fact, it was more erroneous as it had invalid algorithm field).

[jay]

Thanks Emil, landed in 3fa220a. And thanks for the test Dan.

[jay]

Thanks Emil, landed in 3fa220a. And thanks for the test Dan.