commit 6c15c7cce718e1e9a47f4f0ab1bd70923b04557b [browse]
Author: Filippo Valsorda
Date: 2019-09-25 13:34:06 -04:00

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

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

commit ea17f61b1e8dca307b674843fdf9f9408306db97 [browse]
Author: Filippo Valsorda
Date: 2019-09-25 11:18:50 -04:00

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

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

commit 6e6f4aaf70c8b1cc81e65a26332aa9409de03ad8 [browse]
Author: Filippo Valsorda
Date: 2019-09-12 12:37:36 -04:00

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

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 <bradfitz@google.com>
(cherry picked from commit 1280b868e82bf173ea3e988be3092d160ee66082)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/558776
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>

commit 06472b99cdf59f00049f3cd8c9e05ba283cb2c56 [browse]
Author: Dmitri Shuralyov
Date: 2019-08-15 14:10:05 -04:00

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

Change-Id: I70dc0e2accd83d9c974b95075f9e83a82d89563d
Reviewed-on: https://go-review.googlesource.com/c/go/+/190407
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>

commit 8e7eb2f04ca7a908cc09d9cef01ce6f9153a8374 [browse]
Author: Dmitri Shuralyov
Date: 2019-08-15 12:57:01 -04:00

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

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