net/http: insufficient sanitization of Host header

[neild]

The net/http client does not sufficiently sanitize or check the validity of the Request.Host field. A maliciously-crafted Host field can inject request headers or entire new requests into the sent request. For example, setting Request.Host to "hostname\r\nX-Header: oops" adds an X-Header: oops header to the request.

Whether this is a vulnerability or just a bug depends on whether the Request.Host field is expected to be secured against untrusted inputs. We don't document this one way or the other. Exploiting this in practice seems difficult, since it requires requests to be sent using an unsanitized and untrusted Request.Host value, so if this is a vulnerability it seems reasonable to treat it as PUBLIC track. Either way, we should fix it.

This is a continuation of #11206, which reports the same issue but had an incomplete fix.

Thanks to @bartekn for reporting this issue.

[gopherbot]

Change https://go.dev/cl/506995 mentions this issue: http2: validate Host header before sending

[gopherbot]

Change https://go.dev/cl/506996 mentions this issue: net/http: validate Host header before sending

[neild]

@gopherbot please open backport issues. This is a (fairly minor) security issue.

[gopherbot]

Backport issue(s) opened: #61075 (for 1.19), #61076 (for 1.20).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

[gopherbot]

Change https://go.dev/cl/507357 mentions this issue: net/http: validate Host header before sending

[gopherbot]

Change https://go.dev/cl/507358 mentions this issue: net/http: validate Host header before sending

[tatianab]

This is CVE-2023-29406.

[dmitshur]

@neild CL 506995 and CL 506996 both say "For". Is the only thing left to resolve this issue to backport CL 506995 to internal-branch.go1.21-vendor and regenerate src/net/http/h2_bundle.go, or is there more that needs to be done for Go 1.21?

This is being backported to the next 1.20 and 1.19 minor releases, so adding release-blocker here since Go 1.21 shouldn't be released while this issue is still open. (CC @joedian.)