net/http: insufficient sanitization of Host header #60374

neild · 2023-05-23T18:37:59Z

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.

The text was updated successfully, but these errors were encountered:

gopherbot · 2023-06-28T20:22:21Z

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

gopherbot · 2023-06-28T20:24:21Z

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

Verify that the Host header we send is valid. Avoids sending a request that the server will reject, possibly sending us into a retry loop. No test in this CL, but this will be covered by the net/http test added in CL 506996. For golang/go#60374 Change-Id: I78867eb05293ad8ca1b02bc22fb626760949d4b8 Reviewed-on: https://go-review.googlesource.com/c/net/+/506995 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Tatiana Bradley <tatianabradley@google.com>

Verify that the Host header we send is valid. Avoids surprising behavior such as a Host of "go.dev\r\nX-Evil:oops" adding an X-Evil header to HTTP/1 requests. Add a test, skip the test for HTTP/2. HTTP/2 is not vulnerable to header injection in the way HTTP/1 is, but x/net/http2 doesn't validate the header and will go into a retry loop when the server rejects it. CL 506995 adds the necessary validation to x/net/http2. For #60374 Change-Id: I05cb6866a9bead043101954dfded199258c6dd04 Reviewed-on: https://go-review.googlesource.com/c/go/+/506996 Reviewed-by: Tatiana Bradley <tatianabradley@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Damien Neil <dneil@google.com>

neild · 2023-06-29T17:01:06Z

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

gopherbot · 2023-06-29T17:01:31Z

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 · 2023-06-30T18:06:02Z

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

gopherbot · 2023-06-30T18:07:46Z

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

tatianab · 2023-06-30T18:38:35Z

This is CVE-2023-29406.

dmitshur · 2023-07-05T19:50:39Z

@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.)

gopherbot · 2023-07-05T20:52:56Z

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

gopherbot · 2023-07-05T20:53:44Z

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

Verify that the Host header we send is valid. Avoids surprising behavior such as a Host of "go.dev\r\nX-Evil:oops" adding an X-Evil header to HTTP/1 requests. Add a test, skip the test for HTTP/2. HTTP/2 is not vulnerable to header injection in the way HTTP/1 is, but x/net/http2 doesn't validate the header and will go into a retry loop when the server rejects it. CL 506995 adds the necessary validation to x/net/http2. Updates #60374 Fixes #61075 For CVE-2023-29406 Change-Id: I05cb6866a9bead043101954dfded199258c6dd04 Reviewed-on: https://go-review.googlesource.com/c/go/+/506996 Reviewed-by: Tatiana Bradley <tatianabradley@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Damien Neil <dneil@google.com> (cherry picked from commit 499458f) Reviewed-on: https://go-review.googlesource.com/c/go/+/507358 Run-TryBot: Tatiana Bradley <tatianabradley@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org>

Verify that the Host header we send is valid. Avoids surprising behavior such as a Host of "go.dev\r\nX-Evil:oops" adding an X-Evil header to HTTP/1 requests. Add a test, skip the test for HTTP/2. HTTP/2 is not vulnerable to header injection in the way HTTP/1 is, but x/net/http2 doesn't validate the header and will go into a retry loop when the server rejects it. CL 506995 adds the necessary validation to x/net/http2. For #60374 Fixes #61076 For CVE-2023-29406 Change-Id: I05cb6866a9bead043101954dfded199258c6dd04 Reviewed-on: https://go-review.googlesource.com/c/go/+/506996 Reviewed-by: Tatiana Bradley <tatianabradley@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Damien Neil <dneil@google.com> (cherry picked from commit 499458f) Reviewed-on: https://go-review.googlesource.com/c/go/+/507357 Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Tatiana Bradley <tatianabradley@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org>

eliben · 2023-07-07T16:34:57Z

@neild what's the status here?

neild · 2023-07-07T16:36:06Z

Only thing left to resolve is the backports, so I think we can close this one.

In the latest Go version, the net/http client will validate Host header stricter and will fail if it contains invalid characters. For more info, see: - golang/go#60374 - moby/moby#45935 Patch docker temporarily to set Host header to 'localhost' when a UDS is used.

jmurret · 2023-07-14T16:38:13Z

Thank you for this change. This does cause an issue for unix sockets that have hostnames starting with a slash. I think we are seeing the community that uses sockets now have to react to this change and put in conditional logic to check their host and if it begins with a slash or ends with .sock change the host name to something like localhost. Is it possible to have this baked into net/http host header validation?

andresvia · 2023-07-14T19:24:39Z

Thank you for this change. This does cause an issue for unix sockets that have hostnames starting with a slash. I think we are seeing the community that uses sockets now have to react to this change and put in conditional logic to check their host and if it begins with a slash or ends with .sock change the host name to something like localhost. Is it possible to have this baked into net/http host header validation?

@jmurret I will dare to say that the security fix went too hard and broke a feature which many of us relied on and now there's really no right (clean) way to proceed, if the validation gets baked, workarounds will need to remain because there will be always people running some go release which doesn't have the thing baked. I'm sorry I know I'm not really commenting anything useful, I'll just move on with my life 😄 and let you guys think about what you just did.

Verify that the Host header we send is valid. Avoids surprising behavior such as a Host of "go.dev\r\nX-Evil:oops" adding an X-Evil header to HTTP/1 requests. Add a test, skip the test for HTTP/2. HTTP/2 is not vulnerable to header injection in the way HTTP/1 is, but x/net/http2 doesn't validate the header and will go into a retry loop when the server rejects it. CL 506995 adds the necessary validation to x/net/http2. For golang#60374 Change-Id: I05cb6866a9bead043101954dfded199258c6dd04 Reviewed-on: https://go-review.googlesource.com/c/go/+/506996 Reviewed-by: Tatiana Bradley <tatianabradley@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Damien Neil <dneil@google.com>

Go 1.20.6 and 1.19.11 include a security check of the http Host header: golang/go#60374 docker-cli does not satisfy this check: $ docker exec -it ctr bash http: invalid Host header This is a backported patch to fix this issue: Issue: moby/moby#45935 Upstream PR: moby/moby#45942 The upstream PR has been merged and will be included in v24.0.5. Signed-off-by: Christian Stewart <christian@aperture.us>

Historically, the Transport has silently truncated invalid Host headers at the first '/' or ' ' character. CL 506996 changed this behavior to reject invalid Host headers entirely. Unfortunately, Docker appears to rely on the previous behavior. When sending a HTTP/1 request with an invalid Host, send an empty Host header. This is safer than truncation: If you care about the Host, then you should get the one you set; if you don't care, then an empty Host should be fine. Continue to fully validate Host headers sent to a proxy, since proxies generally can't productively forward requests without a Host. For #60374 Fixes #61431 Change-Id: If170c7dd860aa20eb58fe32990fc93af832742b6 Reviewed-on: https://go-review.googlesource.com/c/go/+/511155 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Run-TryBot: Damien Neil <dneil@google.com>

gopherbot · 2023-08-11T17:52:58Z

Change https://go.dev/cl/518855 mentions this issue: [release-branch.go1.19] net/http: permit requests with invalid Host headers

gopherbot · 2023-08-11T17:53:22Z

Change https://go.dev/cl/518756 mentions this issue: [release-branch.go1.20] net/http: permit requests with invalid Host headers

gopherbot · 2023-08-11T17:54:11Z

Change https://go.dev/cl/518856 mentions this issue: [release-branch.go1.21] net/http: permit requests with invalid Host headers

…eaders Historically, the Transport has silently truncated invalid Host headers at the first '/' or ' ' character. CL 506996 changed this behavior to reject invalid Host headers entirely. Unfortunately, Docker appears to rely on the previous behavior. When sending a HTTP/1 request with an invalid Host, send an empty Host header. This is safer than truncation: If you care about the Host, then you should get the one you set; if you don't care, then an empty Host should be fine. Continue to fully validate Host headers sent to a proxy, since proxies generally can't productively forward requests without a Host. For #60374 Fixes #61431 Fixes #61904 Change-Id: If170c7dd860aa20eb58fe32990fc93af832742b6 Reviewed-on: https://go-review.googlesource.com/c/go/+/511155 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Run-TryBot: Damien Neil <dneil@google.com> (cherry picked from commit b9153f6) Reviewed-on: https://go-review.googlesource.com/c/go/+/518856 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Roland Shoemaker <roland@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>

…eaders Historically, the Transport has silently truncated invalid Host headers at the first '/' or ' ' character. CL 506996 changed this behavior to reject invalid Host headers entirely. Unfortunately, Docker appears to rely on the previous behavior. When sending a HTTP/1 request with an invalid Host, send an empty Host header. This is safer than truncation: If you care about the Host, then you should get the one you set; if you don't care, then an empty Host should be fine. Continue to fully validate Host headers sent to a proxy, since proxies generally can't productively forward requests without a Host. For #60374 Fixes #61431 Fixes #61826 Change-Id: If170c7dd860aa20eb58fe32990fc93af832742b6 Reviewed-on: https://go-review.googlesource.com/c/go/+/511155 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Run-TryBot: Damien Neil <dneil@google.com> (cherry picked from commit b9153f6) Reviewed-on: https://go-review.googlesource.com/c/go/+/518756 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Roland Shoemaker <roland@golang.org>

…eaders Historically, the Transport has silently truncated invalid Host headers at the first '/' or ' ' character. CL 506996 changed this behavior to reject invalid Host headers entirely. Unfortunately, Docker appears to rely on the previous behavior. When sending a HTTP/1 request with an invalid Host, send an empty Host header. This is safer than truncation: If you care about the Host, then you should get the one you set; if you don't care, then an empty Host should be fine. Continue to fully validate Host headers sent to a proxy, since proxies generally can't productively forward requests without a Host. For #60374 Fixes #61431 Fixes #61825 Change-Id: If170c7dd860aa20eb58fe32990fc93af832742b6 Reviewed-on: https://go-review.googlesource.com/c/go/+/511155 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Run-TryBot: Damien Neil <dneil@google.com> (cherry picked from commit b9153f6) Reviewed-on: https://go-review.googlesource.com/c/go/+/518855 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Roland Shoemaker <roland@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>

…onnections to UNIX domain sockets. As of golang/go#60374 (in the latest Go releases at the time of this writing), we must set it to something that looks like a hostname or requests will fail.

…22523) The Host part of the URL doesn't actually get used when we initiate connections to UNIX domain sockets. As of golang/go#60374 (in the latest Go releases at the time of this writing), we must set it to something that looks like a hostname or requests will fail.

Go 1.20.6 and 1.19.11 include a security check of the http Host header: golang/go#60374 docker-cli does not satisfy this check: $ docker exec -it ctr bash http: invalid Host header This is a backported patch to fix this issue: Issue: moby/moby#45935 Upstream PR: moby/moby#45942 The upstream PR has been merged and will be included in v24.0.5. Signed-off-by: Christian Stewart <christian@aperture.us> Tested-by: TIAN Yuanhao <tianyuanhao3@163.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

neild self-assigned this May 23, 2023

bcmills added Security NeedsFix The path to resolution is known, but the work has not been done. labels May 23, 2023

This was referenced Jun 29, 2023

net/http: insufficient sanitization of Host header [1.19 backport] #61075

Closed

net/http: insufficient sanitization of Host header [1.20 backport] #61076

Closed

dmitshur added this to the Go1.21 milestone Jul 5, 2023

dmitshur added the release-blocker label Jul 5, 2023

neild closed this as completed Jul 7, 2023

tklauser mentioned this issue Jul 12, 2023

chore(deps): update go to v1.20.6 (main) (patch) cilium/cilium#26781

Merged

1 task

jmurret mentioned this issue Jul 14, 2023

[NET-4897] net/http host header is now verified and request.host that contains socked now error hashicorp/consul#18129

Merged

4 tasks

ncabatoff mentioned this issue Aug 23, 2023

Work around issue with UNIX domain sockets in api.Client addresses hashicorp/vault#22523

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

net/http: insufficient sanitization of Host header #60374

net/http: insufficient sanitization of Host header #60374

neild commented May 23, 2023

gopherbot commented Jun 28, 2023

gopherbot commented Jun 28, 2023

neild commented Jun 29, 2023

gopherbot commented Jun 29, 2023

gopherbot commented Jun 30, 2023

gopherbot commented Jun 30, 2023

tatianab commented Jun 30, 2023

dmitshur commented Jul 5, 2023 •

edited

gopherbot commented Jul 5, 2023

gopherbot commented Jul 5, 2023

eliben commented Jul 7, 2023

neild commented Jul 7, 2023

jmurret commented Jul 14, 2023 •

edited

andresvia commented Jul 14, 2023

gopherbot commented Aug 11, 2023

gopherbot commented Aug 11, 2023

gopherbot commented Aug 11, 2023

net/http: insufficient sanitization of Host header #60374

net/http: insufficient sanitization of Host header #60374

Comments

neild commented May 23, 2023

gopherbot commented Jun 28, 2023

gopherbot commented Jun 28, 2023

neild commented Jun 29, 2023

gopherbot commented Jun 29, 2023

gopherbot commented Jun 30, 2023

gopherbot commented Jun 30, 2023

tatianab commented Jun 30, 2023

dmitshur commented Jul 5, 2023 • edited

gopherbot commented Jul 5, 2023

gopherbot commented Jul 5, 2023

eliben commented Jul 7, 2023

neild commented Jul 7, 2023

jmurret commented Jul 14, 2023 • edited

andresvia commented Jul 14, 2023

gopherbot commented Aug 11, 2023

gopherbot commented Aug 11, 2023

gopherbot commented Aug 11, 2023

dmitshur commented Jul 5, 2023 •

edited

jmurret commented Jul 14, 2023 •

edited