go, branch go1.13.2

[release-branch.go1.13-security] go1.13.2

2019-10-17T17:32:17Z

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

[release-branch.go1.13-security] doc: document Go 1.13.2 and Go 1.12.11

2019-10-17T15:57:02Z

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

[release-branch.go1.13-security] cmd/compile: make poset use sufficient conditions for OrderedOrEqual

2019-10-17T15:56:46Z

When assessing whether A <= B, the poset's OrderedOrEqual has a passing condition which permits A <= B, but is not sufficient to infer that A <= B. This CL removes that incorrect passing condition. Having identified that A and B are in the poset, the method will report that A <= B if any of these three conditions are true: (1) A and B are the same node in the poset. - This means we know that A == B. (2) There is a directed path, strict or not, from A -> B - This means we know that, at least, A <= B, but A < B is possible. (3) There is a directed path from B -> A, AND that path has no strict edges. - This means we know that B <= A, but do not know that B < A. In condition (3), we do not have enough information to say that A <= B, rather we only know that B == A (which satisfies A <= B) is possible. The way I understand it, a strict edge shows a known, strictly-ordered relation (<) but the lack of a strict edge does not show the lack of a strictly-ordered relation. The difference is highlighted by the example in #34802, where a bounds check is incorrectly removed by prove, such that negative indexes into a slice succeed: n := make([]int, 1) for i := -1; i <= 0; i++ { fmt.Printf("i is %d\n", i) n[i] = 1 // No Bounds check, program runs, assignment to n[-1] succeeds!! } When prove is checking the negative/failed branch from the bounds check at n[i], in the signed domain we learn (0 > i || i >= len(n)). Because prove can't learn the OR condition, we check whether we know that i is non-negative so we can learn something, namely that i >= len(n). Prove uses the poset to check whether we know that i is non-negative. At this point the poset holds the following relations as a directed graph: -1 <= i <= 0 -1 < 0 In poset.OrderedOrEqual, we are testing for 0 <= i. In this case, condition (3) above is true because there is a non-strict path from i -> 0, and that path does NOT have any strict edges. Because this condition is true, the poset reports to prove that i is known to be >= 0. Knowing, incorrectly, that i >= 0, prove learns from the failed bounds check that i >= len(n) in the signed domain. When the slice, n, was created, prove learned that len(n) == 1. Because i is also the induction variable for the loop, upon entering the loop, prove previously learned that i is in [-1,0]. So when prove attempts to learn from the failed bounds check, it finds the new fact, i > len(n), unsatisfiable given that it previously learned that i <= 0 and len(n) = 1. Fixes #34807 Change-Id: I235f4224bef97700c3aa5c01edcc595eb9f13afc Reviewed-on: https://go-review.googlesource.com/c/go/+/200759 Run-TryBot: Zach Jones TryBot-Result: Gobot Gobot Reviewed-by: Giovanni Bajo Reviewed-by: Keith Randall Reviewed-on: https://go-review.googlesource.com/c/go/+/201060 Run-TryBot: Alexander Rakoczy Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/575398 Reviewed-by: Filippo Valsorda

[release-branch.go1.13-security] cmd/compile: rename poset method dominates to reaches

2019-10-17T15:56:30Z

The partially ordered set uses a method named 'dominates' to determine whether two nodes are partially ordered. Dominates does a depth-first search of the DAG, beginning at the source node, and returns true as soon as it finds a path to the target node. In the context of the forest-of-DAGs that makes up the poset, dominates is not necessarily checking dominance, but is checking reachability. See the issue tracker for a more detailed discussion of the difference. Fortunately, reachability is logically correct everywhere dominates is currently used in poset.go. Reachability within a DAG is sufficient to establish the partial ordering (source < target). This CL changes the name of the method (dominates -> reaches) and updates all the comments in the file accordingly. Updates #34807 Change-Id: Ia3a34f7b14b363801d75b05099cfc686035f7d96 Reviewed-on: https://go-review.googlesource.com/c/go/+/192617 Reviewed-by: Giovanni Bajo Run-TryBot: Giovanni Bajo TryBot-Result: Gobot Gobot Reviewed-on: https://go-review.googlesource.com/c/go/+/201059 Run-TryBot: Alexander Rakoczy Reviewed-by: Keith Randall Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/575397 Reviewed-by: Filippo Valsorda

[release-branch.go1.13-security] crypto/dsa: prevent bad public keys from causing panic

2019-10-16T23:10:06Z

dsa.Verify might currently use a nil s inverse in a multiplication if the public key contains a non-prime Q, causing a panic. Change this to check that the mod inverse exists before using it. Fixes CVE-2019-17596 Change-Id: I94d5f3cc38f1b5d52d38dcb1d253c71b7fd1cae7 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/572809 Reviewed-by: Filippo Valsorda (cherry picked from commit 9119dfb0511326d4485b248b83d4fde19c95d0f7) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/575233

[release-branch.go1.13-security] go1.13.1

2019-09-25T18:48:17Z

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

[release-branch.go1.13-security] doc: add Go 1.13 to release history

2019-09-25T17:33:40Z

Change-Id: I3340561c0b17bf28d8d480e00f5bc8afb2a897ef Reviewed-on: https://go-review.googlesource.com/c/go/+/193042 Run-TryBot: Andrew Bonventre Reviewed-by: Katie Hockman Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/558786 Reviewed-by: Dmitri Shuralyov

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

2019-09-25T17:15:11Z

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/+/558935 Reviewed-by: Dmitri Shuralyov

[release-branch.go1.13-security] doc: document Go 1.13.1 and Go 1.12.10

2019-09-25T17:12:25Z

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

[release-branch.go1.13] go1.13

2019-09-03T17:05:17Z

Change-Id: Iad80da6df9a6f9a39458e1060bed3557a5ed89a4 Reviewed-on: https://go-review.googlesource.com/c/go/+/193037 Run-TryBot: Andrew Bonventre TryBot-Result: Gobot Gobot Reviewed-by: Bryan C. Mills Reviewed-by: Alexander Rakoczy Reviewed-by: Filippo Valsorda Reviewed-by: Brad Fitzpatrick Reviewed-by: Andrew Bonventre