digest: SASL DIGEST-MD5 response does not escape realm/nonce values

[cooldadpresident]

Summary

Curl_auth_create_digest_md5_message() in lib/vauth/digest.c inserts server-provided realm and nonce values into the SASL DIGEST-MD5 response without escaping double-quote or backslash characters. The HTTP Digest path in the same file correctly uses auth_digest_string_quoted() for these values.

The bug

The SASL challenge decoder auth_digest_get_key_value() (line 210-215) strips backslash escapes from quoted values. After de-escaping, values can contain literal " characters. These are then inserted raw into the response at line 469:

response = curl_maprintf("username=\"%s\",realm=\"%s\",nonce=\"%s\","
                         "cnonce=\"%s\",nc=\"%s\",digest-uri=\"%s\","
                         "response=%s,qop=%s",
                         userp, realm, nonce,
                         cnonce, nonceCount, spn, resp_hash_hex, qop);

The HTTP Digest path (line 849-866) handles this correctly:

realm_quoted = auth_digest_string_quoted(digest->realm);
nonce_quoted = auth_digest_string_quoted(digest->nonce);

Reproduction

1. Set up an SMTP server advertising AUTH DIGEST-MD5
2. Send a challenge containing realm="test\"break" (valid escaped quote per RFC 2831)
3. Decode curl's base64 SASL response

Expected response: realm="test\"break"
Actual response: realm="test"break" — unescaped quote breaks the quoted-string format

Verified against curl 8.19.0-DEV (commit 1acf0c4) using a mock SMTP server PoC.

A crafted nonce value can also inject arbitrary top-level fields into the response. For example, nonce="OA6MG\",injected=\"evil" produces nonce="OA6MG",injected="evil" in curl's output.

Affected protocols

SMTP, IMAP, POP3 — all protocols using SASL DIGEST-MD5 via curl_sasl.c line 671.

Fix

Call auth_digest_string_quoted() on realm and nonce before inserting them into the SASL response string, matching the HTTP Digest path.

AI disclosure

This issue was found with the assistance of AI tooling. The finding was verified manually with a working PoC against a locally built curl 8.19.0-DEV binary.

[michael-o]

FTR: https://datatracker.ietf.org/doc/html/rfc6331

[bagder]

Hm, the checksum is still calculated on the un-escaped string, isn't it?

I also realize that I can't find a single test case providing a realm for SMTP, IMAP or POP3. We should work on that!

[bagder]

No, we have tests for it, just hard to find since the data is bas64 encoded. I'll work on adding one using double quote.

[cooldadpresident]

Correct — the hash is computed on the un-escaped (raw) values. The escaping via auth_digest_string_quoted() should only be applied when formatting the output string, keeping the hash inputs untouched.

Thanks for the quick fix and the additional test coverage! I truly apprecitate your work an time. Thanks a lot and I look forward to future contributions.