Skip to content

G
go
Switch branch/tag
  1. 17 Oct, 2019 2 commits
  3. 16 Oct, 2019 1 commit
  5. 25 Sep, 2019 3 commits
  7. 15 Aug, 2019 2 commits
  9. 13 Aug, 2019 3 commits
  11. 12 Aug, 2019 2 commits
    • Filippo Valsorda's avatar
      [release-branch.go1.12-security] net/url: make Hostname and Port predictable... · 3226f2d4
      Filippo Valsorda authored 
      [release-branch.go1.12-security] net/url: make Hostname and Port predictable for invalid Host values

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/+/189258Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
(cherry picked from commit 61bb56ad)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526408Reviewed-by: default avatarDmitri Shuralyov <dmitshur@google.com>
      3226f2d4
    • Filippo Valsorda's avatar
      [release-branch.go1.12-security] net/http: update bundled http2 to import security fix · 7139b45d
      Filippo Valsorda authored 
      Apply the following unpublished golang.org/x/net commit.

    commit cdfb69ac37fc6fa907650654115ebebb3aae2087
    Author: Filippo Valsorda <filippo@golang.org>
    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/+/525552Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@google.com>
    (cherry picked from commit 589ad6cc5321fb68a90370348a241a5da0a2cc80)
    Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526069Reviewed-by: default avatarDmitri Shuralyov <dmitshur@google.com>

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/+/526071Reviewed-by: default avatarDmitri Shuralyov <dmitshur@google.com>
      7139b45d
  13. 09 Aug, 2019 1 commit
  15. 02 Aug, 2019 2 commits
  17. 31 Jul, 2019 1 commit
  19. 16 Jul, 2019 1 commit
  21. 15 Jul, 2019 1 commit
  23. 08 Jul, 2019 6 commits
  25. 01 Jul, 2019 1 commit
  27. 26 Jun, 2019 1 commit
    • Ian Lance Taylor's avatar
      [release-branch.go1.12] cmd/cgo: fix inappropriate array copy · 77c14d29
      Ian Lance Taylor authored 
      Ensure that during rewriting of expressions that take the address of
an array, that we properly recognize *ast.IndexExpr as an operation
to create a pointer variable and thus assign the proper addressOf
and deference operators as "&" and "*" respectively.

This fixes a regression from CL 142884.

This is a backport of CLs 183458 and 183778 to the 1.12 release branch.
It is not a cherry pick because the code in misc/cgo/test has changed.

Updates #32579
Fixes #32756

Change-Id: I0daa75ec62cccbe82ab658cb2947f51423e0c235
Reviewed-on: https://go-review.googlesource.com/c/go/+/183627
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarEmmanuel Odeke <emm.odeke@gmail.com>
      77c14d29
  29. 11 Jun, 2019 3 commits
  31. 10 Jun, 2019 2 commits
  33. 07 Jun, 2019 3 commits
  35. 17 May, 2019 1 commit
    • Jason A. Donenfeld's avatar
      [release-branch.go1.12] os: pass correct environment when creating Windows processes · afcfe0d3
      Jason A. Donenfeld authored 
      This is CVE-2019-11888.

Previously, passing a nil environment but a non-nil token would result
in the new potentially unprivileged process inheriting the parent
potentially privileged environment, or would result in the new
potentially privileged process inheriting the parent potentially
unprivileged environment. Either way, it's bad. In the former case, it's
an infoleak. In the latter case, it's a possible EoP, since things like
PATH could be overwritten.

Not specifying an environment currently means, "use the existing
environment". This commit amends the behavior to be, "use the existing
environment of the token the process is being created for." The behavior
therefore stays the same when creating processes without specifying a
token. And it does the correct thing when creating processes when
specifying a token.

Updates #32000
Fixes #32081

Change-Id: Ib4a90cfffb6ba866c855f66f1313372fdd34ce41
Reviewed-on: https://go-review.googlesource.com/c/go/+/177538
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      afcfe0d3
  37. 14 May, 2019 1 commit
  39. 08 May, 2019 1 commit
  41. 06 May, 2019 2 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7