The client connects through an HTTP CONNECT proxy with the proxy_auth_fun option set, and the callback builds its result from data an untrusted party can influence, such as the proxy's 407 challenge headers. Deployments without proxy_auth_fun, or whose callback returns a fixed credential, are not affected.
Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting') vulnerability in hackney_http_connect in benoitc hackney allows HTTP Request Splitting via the value a proxy_auth_fun callback returns. After a 407 response from an HTTP CONNECT proxy, hackney_http_connect:handle_proxy_auth/11 calls the caller's proxy_auth_fun with the status code and the response headers and writes the returned binary into the Proxy-Authorization line of the CONNECT retry without checking it. A CR, LF or NUL byte in that value adds header lines to the request sent to the proxy.
The value is attacker-influenced when the callback derives it from untrusted data, for example from the proxy's challenge headers. Other caller-supplied values on the CONNECT path, such as the target host and the request headers, were already checked for control bytes.
\nThis issue affects hackney: from 2.0.0 before 4.9.0.
"},{"base64":false,"type":"text/markdown","value":"Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting') vulnerability in `hackney_http_connect` in benoitc hackney allows HTTP Request Splitting via the value a `proxy_auth_fun` callback returns. After a 407 response from an HTTP CONNECT proxy, `hackney_http_connect:handle_proxy_auth/11` calls the caller's `proxy_auth_fun` with the status code and the response headers and writes the returned binary into the `Proxy-Authorization` line of the CONNECT retry without checking it. A CR, LF or NUL byte in that value adds header lines to the request sent to the proxy.\n\nThe value is attacker-influenced when the callback derives it from untrusted data, for example from the proxy's challenge headers. Other caller-supplied values on the CONNECT path, such as the target host and the request headers, were already checked for control bytes.\n\nThis issue affects hackney: from 2.0.0 before 4.9.0."}],"value":"Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting') vulnerability in hackney_http_connect in benoitc hackney allows HTTP Request Splitting via the value a proxy_auth_fun callback returns. After a 407 response from an HTTP CONNECT proxy, hackney_http_connect:handle_proxy_auth/11 calls the caller's proxy_auth_fun with the status code and the response headers and writes the returned binary into the Proxy-Authorization line of the CONNECT retry without checking it. A CR, LF or NUL byte in that value adds header lines to the request sent to the proxy.\n\nThe value is attacker-influenced when the callback derives it from untrusted data, for example from the proxy's challenge headers. Other caller-supplied values on the CONNECT path, such as the target host and the request headers, were already checked for control bytes.\n\nThis issue affects hackney: from 2.0.0 before 4.9.0."}],"impacts":[{"capecId":"CAPEC-105","descriptions":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"A party who controls what the application's proxy_auth_fun returns, for instance through the challenge headers of a proxy it can influence, can add header lines to the CONNECT request the client sends to its proxy.
Check the value your proxy_auth_fun is about to return for CR, LF and NUL bytes and return {error, Reason} instead when one is present. The callback runs in the application, so the check can be made there.
1. Challenge. hackney_http_connect:do_handshake_with_auth/9 in src/hackney_http_connect.erl sends the CONNECT request to the proxy. When the proxy answers 407 and the proxy_auth_fun option is set, it hands the status code and the parsed response headers to hackney_http_connect:handle_proxy_auth/11.
2. Callback result. handle_proxy_auth/11 calls the caller's proxy_auth_fun with those two values. On {ok, AuthHeader} it removes any existing Proxy-Authorization header and appends the binary <<\"Proxy-Authorization: \", AuthHeader/binary>> to the header list, then retries the handshake with it.
3. Splitting. The header list is joined with CRLF into the CONNECT request. A CR, LF or NUL byte inside AuthHeader therefore ends the Proxy-Authorization line early and the rest is sent as further header lines. The target host and the request headers go through control-byte checks on this path; the callback result did not. The fix applies the same has_ctl_bytes/1 check to it and returns {error, {proxy_auth_error, invalid_header}}.