Go 1.11.3 fixes package retrieval and certificate verification
The security release restricts malicious import paths in GOPATH mode and bounds certificate-chain signature checks. Build tools and deployed programs need different responses.
Fetching source code and rejecting an untrusted certificate are operations that programs perform before deciding to trust something. Both operations still have to process attacker-controlled input. Go's latest security release addresses failures in those boundaries, including code execution through package retrieval and excessive CPU work during certificate-chain verification.
The release history dates Go 1.11.3 to December 12. Dmitri Shuralyov's public security announcement is dated December 13 and identifies the three issues. It recommends updating to Go 1.11.3 or the corresponding Go 1.10.6 release. The disclosure provides enough detail to distinguish a development-tool exposure from a vulnerability in running applications.
I value Go's straightforward tooling, but a convenient command still needs a precise security contract. Downloading and building code should not silently give repository metadata the authority to run unrelated commands. The first of these reports shows how that boundary can fail before an application is executed.
Repository contents can become Git configuration
Issue 29230, CVE-2018-16873, concerns go get -u in GOPATH mode. An attacker can arrange a vanity import path so a repository is cloned into a directory named .git. With specially arranged repository contents and operation ordering, the command can then treat the parent as a Git repository.
The important transition is that downloaded data becomes repository control information. Files that arrived as the contents of one repository can be interpreted as Git metadata for another location. Git commands then consult the attacker's configuration, which can contain commands that execute on the fetching machine. The issue describes a route through direct or indirect imports, so the malicious package need not be the application author's immediate dependency choice.
The report explicitly limits this vulnerability to GOPATH mode. Module mode is not affected by this issue. That does not justify treating module mode as a universal security guarantee. It identifies the retrieval implementation involved and helps determine which command invocations are exposed to this particular flaw.
The issue also warns that simply forbidding the literal .git spelling may not be sufficient on systems with aliases for version-control state directories. That is a reason to examine the interpretation of the path as a whole. A textual check must account for how the receiving filesystem and tool interpret the name.
Import-path processing can escape its intended directory
Issue 29231, CVE-2018-16874, concerns malicious import paths containing curly braces. The disclosed result is directory traversal in GOPATH-mode go get, with arbitrary filesystem writes that can lead to code execution. Module mode is again outside the affected path described by the report.
This is a different mechanism from the repository-metadata confusion. Both begin with an import path supplied through dependency retrieval, but one changes how Git interprets downloaded files while the other permits writes beyond the intended location. Treating them as interchangeable would make it harder to understand why input restrictions have to protect more than one operation.
An import path has several roles in this workflow. It identifies source to obtain and contributes to locating that source in a workspace. Once its characters influence filesystem operations or another tool's arguments, their interpretation matters. This is the broader engineering consequence of the report, rather than a claim that every unusual path spelling is exploitable.
Updating the go command addresses the tool performing these operations. It does not require waiting for a deployed service to receive a request. A development machine or build worker can encounter the vulnerable behavior while retrieving dependencies. That makes the build environment part of the response to this release.
Rejecting a certificate can consume too much CPU
Issue 29233, CVE-2018-16875, describes unbounded work in crypto/x509 chain verification. Carefully chosen input can make the verifier spend excessive CPU time searching and checking candidate chains. TLS clients verifying certificates and TLS servers accepting client certificates are affected.
The attacker does not need the verifier to accept a forged chain for this class of failure to matter. Resource use occurs while the program evaluates the input. A decision that eventually rejects a certificate can still be too expensive when repeated. This makes bounded verification work part of handling untrusted certificates correctly.
The Go 1.11.3 verifier source introduces a limit of 100 signature-check attempts in chain construction. The recursive calls share a counter. That detail matters because independent per-branch limits would not provide the same bound across the search.
The limit is not a declaration that a valid certificate chain may contain 100 certificates. It counts attempts to check signatures while considering candidate issuers. Several candidates can require work even when the resulting chain is short. The source comments explain that the budget allows room for multiple chains and failed checks involving intermediates with the same subject.
I prefer a bound on the actual expensive operation to an explanation that relies only on normal-looking inputs. A verifier must account for the work an adversary can request. Here the counter makes that cost explicit in the chain-building algorithm.
The corrected toolchain and deployed binary have separate roles
The retrieval fixes protect invocations of the updated command. The certificate-verification fix has to be present in the program performing verification. Rebuilding and replacing an affected application is therefore a different task from installing a new compiler on the machine that builds it. The distinction follows directly from which component executes each vulnerable operation.
The announcement also reports a known regression in GOPATH-mode go get for import patterns containing ... when downloading packages not already present in the workspace. It identifies issue 29241 and says another patch is planned. That is the state of the information available today. The security recommendation and the documented functionality regression both need to remain visible to someone responsible for package retrieval.
An application's exposure consequently depends on which operation it performs. Dependency retrieval needs the corrected command in the environment that runs it. Certificate validation needs the corrected library implementation in the executing application. The release addresses both, but replacing one component does not establish that the other has changed.