go, branch go1.12.10

[release-branch.go1.12-security] go1.12.10

2019-09-25T18:48:21Z

Change-Id: I64d76a35ad113110cb83117c6ce5d4d923d93c93 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/558789 Reviewed-by: Dmitri Shuralyov

[release-branch.go1.12-security] doc: document Go 1.12.10

2019-09-25T17:22:36Z

Change-Id: If694ce529393b8ae9c6c55270665efc3a108a3b2 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/558778 Reviewed-by: Dmitri Shuralyov Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/558784

[release-branch.go1.12-security] net/textproto: don't normalize headers with spaces before the colon

2019-09-25T17:15:22Z

RFC 7230 is clear about headers with a space before the colon, like X-Answer : 42 being invalid, but we've been accepting and normalizing them for compatibility purposes since CL 5690059 in 2012. On the client side, this is harmless and indeed most browsers behave the same to this day. On the server side, this becomes a security issue when the behavior doesn't match that of a reverse proxy sitting in front of the server. For example, if a WAF accepts them without normalizing them, it might be possible to bypass its filters, because the Go server would interpret the header differently. Worse, if the reverse proxy coalesces requests onto a single HTTP/1.1 connection to a Go server, the understanding of the request boundaries can get out of sync between them, allowing an attacker to tack an arbitrary method and path onto a request by other clients, including authentication headers unknown to the attacker. This was recently presented at multiple security conferences: https://portswigger.net/blog/http-desync-attacks-request-smuggling-reborn net/http servers already reject header keys with invalid characters. Simply stop normalizing extra spaces in net/textproto, let it return them unchanged like it does for other invalid headers, and let net/http enforce RFC 7230, which is HTTP specific. This loses us normalization on the client side, but there's no right answer on the client side anyway, and hiding the issue sounds worse than letting the application decide. Fixes CVE-2019-16276 Change-Id: I6d272de827e0870da85d93df770d6a0e161bbcf1 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/549719 Reviewed-by: Brad Fitzpatrick (cherry picked from commit 1280b868e82bf173ea3e988be3092d160ee66082) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/558776 Reviewed-by: Dmitri Shuralyov

[release-branch.go1.12] go1.12.9

2019-08-15T18:44:01Z

Change-Id: I70dc0e2accd83d9c974b95075f9e83a82d89563d Reviewed-on: https://go-review.googlesource.com/c/go/+/190407 Run-TryBot: Dmitri Shuralyov TryBot-Result: Gobot Gobot Reviewed-by: Alexander Rakoczy

[release-branch.go1.12] doc: document Go 1.12.9

2019-08-15T17:54:39Z

Change-Id: I88b7e085fc70f9c021788d364099f5bc6b705ba8 Reviewed-on: https://go-review.googlesource.com/c/go/+/190438 Reviewed-by: Filippo Valsorda (cherry picked from commit 0212f0410f845815f5327a7f2e705891a9598f3d) Reviewed-on: https://go-review.googlesource.com/c/go/+/190406 Reviewed-by: Alexander Rakoczy

[release-branch.go1.12] all: merge release-branch.go1.12-security into release-branch.go1.12

2019-08-13T17:14:07Z

Change-Id: I29801b98d975da0bbc092b16dc9771564a39a10a

[release-branch.go1.12-security] go1.12.8

2019-08-13T16:27:09Z

Change-Id: I131f93770f9bc5f2d4ee73f158607c1c9e1550bb Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/527000 Reviewed-by: Filippo Valsorda

[release-branch.go1.12-security] doc: document Go 1.12.8 and Go 1.11.13

2019-08-13T14:47:02Z

Change-Id: I0daab6cd347e1fc0066e516f02c33f1b63e3f1a3 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526992 Reviewed-by: Filippo Valsorda (cherry picked from commit 685bfb1adec3d9fcb589f35eb2bc0b99d2f84bf0) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526993

[release-branch.go1.12-security] net/url: make Hostname and Port predictable for invalid Host values

2019-08-12T23:49:46Z

When Host is not valid per RFC 3986, the behavior of Hostname and Port was wildly unpredictable, to the point that Host could have a suffix that didn't appear in neither Hostname nor Port. This is a security issue when applications are applying checks to Host and expecting them to be meaningful for the contents of Hostname. To reduce disruption, this change only aims to guarantee the following two security-relevant invariants. * Host is either Hostname or [Hostname] with Port empty, or Hostname:Port or [Hostname]:Port. * Port is only decimals. The second invariant is the one that's most likely to cause disruption, but I believe it's important, as it's conceivable an application might do a suffix check on Host and expect it to be meaningful for the contents of Hostname (if the suffix is not a valid port). There are three ways to ensure it. 1) Reject invalid ports in Parse. Note that non-numeric ports are already rejected if and only if the host starts with "[". 2) Consider non-numeric ports as part of Hostname, not Port. 3) Allow non-numeric ports, and hope they only flow down to net/http, which will reject them (#14353). This change adopts both 1 and 2. We could do only the latter, but then these invalid hosts would flow past port checks, like in http_test.TestTransportRejectsAlphaPort. Non-numeric ports weren't fully supported anyway, because they were rejected after IPv6 literals, so this restores consistency. We could do only the former, but at this point 2) is free and might help with manually constructed Host values (or if we get something wrong in Parse). Note that net.SplitHostPort and net.Dial explicitly accept service names in place of port numbers, but this is an URL package, and RFC 3986, Section 3.2.3, clearly specifies ports as a number in decimal. net/http uses a mix of net.SplitHostPort and url.Parse that would deserve looking into, but in general it seems that it will still accept service names in Addr fields as they are passed to net.Listen, while rejecting them in URLs, which feels correct. This leaves a number of invalid URLs to reject, which however are not security relevant once the two invariants above hold, so can be done in Go 1.14: IPv6 literals without brackets (#31024), invalid IPv6 literals, hostnames with invalid characters, and more. Tested with 200M executions of go-fuzz and the following Fuzz function. u, err := url.Parse(string(data)) if err != nil { return 0 } h := u.Hostname() p := u.Port() switch u.Host { case h + ":" + p: return 1 case "[" + h + "]:" + p: return 1 case h: fallthrough case "[" + h + "]": if p != "" { panic("unexpected Port()") } return 1 } panic("Host is not a variant of [Hostname]:Port") Fixes CVE-2019-14809 Updates #29098 Change-Id: I7ef40823dab28f29511329fa2d5a7fb10c3ec895 Reviewed-on: https://go-review.googlesource.com/c/go/+/189258 Reviewed-by: Ian Lance Taylor (cherry picked from commit 61bb56ad63992a3199acc55b2537c8355ef887b6) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526408 Reviewed-by: Dmitri Shuralyov

[release-branch.go1.12-security] net/http: update bundled http2 to import security fix

2019-08-12T21:44:22Z

Apply the following unpublished golang.org/x/net commit. commit cdfb69ac37fc6fa907650654115ebebb3aae2087 Author: Filippo Valsorda Date: Sun Aug 11 02:12:18 2019 -0400 [release-branch.go1.12] http2: limit number of control frames in server send queue An attacker could cause servers to queue an unlimited number of PING ACKs or RST_STREAM frames by soliciting them and not reading them, until the program runs out of memory. Limit control frames in the queue to a few thousands (matching the limit imposed by other vendors) by counting as they enter and exit the scheduler, so the protection will work with any WriteScheduler. Once the limit is exceeded, close the connection, as we have no way to communicate with the peer. Change-Id: I842968fc6ed3eac654b497ade8cea86f7267886b Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/525552 Reviewed-by: Brad Fitzpatrick (cherry picked from commit 589ad6cc5321fb68a90370348a241a5da0a2cc80) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526069 Reviewed-by: Dmitri Shuralyov Fixes CVE-2019-9512 and CVE-2019-9514 Updates #33606 Change-Id: I282b3e0fa22422d9ea0d07f4a3935685ce4a7433 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526071 Reviewed-by: Dmitri Shuralyov