Skip to content

[release/1.3] Update Golang 1.12.16, x/crypto (CVE-2020-0601, CVE-2020-7919)#3989

Merged
estesp merged 2 commits intocontainerd:release/1.3from
thaJeztah:1.3_bump_golang_1.12.16
Jan 29, 2020
Merged

[release/1.3] Update Golang 1.12.16, x/crypto (CVE-2020-0601, CVE-2020-7919)#3989
estesp merged 2 commits intocontainerd:release/1.3from
thaJeztah:1.3_bump_golang_1.12.16

Conversation

@thaJeztah
Copy link
Copy Markdown
Member

@thaJeztah thaJeztah commented Jan 28, 2020

Update Golang 1.12.16 (CVE-2020-0601, CVE-2020-7919)

full diff: golang/go@go1.12.15...go1.12.16

go1.12.16 (released 2020/01/28) includes two security fixes. One mitigates the
CVE-2020-0601 certificate verification bypass on Windows. The other affects only
32-bit architectures.

https://github.com/golang/go/issues?q=milestone%3AGo1.12.16+label%3ACherryPickApproved

  • X.509 certificate validation bypass on Windows 10
    A Windows vulnerability allows attackers to spoof valid certificate chains when
    the system root store is in use. These releases include a mitigation for Go
    applications, but it’s strongly recommended that affected users install the
    Windows security update to protect their system.
    This issue is CVE-2020-0601 and Go issue golang.org/issue/36834.
  • Panic in crypto/x509 certificate parsing and golang.org/x/crypto/cryptobyte
    On 32-bit architectures, a malformed input to crypto/x509 or the ASN.1 parsing
    functions of golang.org/x/crypto/cryptobyte can lead to a panic.
    The malformed certificate can be delivered via a crypto/tls connection to a
    client, or to a server that accepts client certificates. net/http clients can
    be made to crash by an HTTPS server, while net/http servers that accept client
    certificates will recover the panic and are unaffected.
    Thanks to Project Wycheproof for providing the test cases that led to the
    discovery of this issue. The issue is CVE-2020-7919 and Go issue golang.org/issue/36837.
    This is also fixed in version v0.0.0-20200124225646-8b5121be2f68 of golang.org/x/crypto/cryptobyte.

vendor: update golang.org/x/crypto 69ecbb4d6d5dab05e49161c6e77ea40a030884e1

full diff: golang/crypto@5c40567...69ecbb4

Includes golang/crypto@69ecbb4
(forward-port of golang/crypto@8b5121b),
which fixes CVE-2020-7919:

Panic in crypto/x509 certificate parsing and golang.org/x/crypto/cryptobyte
On 32-bit architectures, a malformed input to crypto/x509 or the ASN.1 parsing
functions of golang.org/x/crypto/cryptobyte can lead to a panic.
The malformed certificate can be delivered via a crypto/tls connection to a
client, or to a server that accepts client certificates. net/http clients can
be made to crash by an HTTPS server, while net/http servers that accept client
certificates will recover the panic and are unaffected.
Thanks to Project Wycheproof for providing the test cases that led to the
discovery of this issue. The issue is CVE-2020-7919 and Go issue golang.org/issue/36837.

@thaJeztah
Update Golang 1.12.16 (CVE-2020-0601, CVE-2020-7919)
d1e31f9 
full diff: golang/go@go1.12.15...go1.12.16

go1.12.16 (released 2020/01/28) includes two security fixes. One mitigates the
CVE-2020-0601 certificate verification bypass on Windows. The other affects only
32-bit architectures.

https://github.com/golang/go/issues?q=milestone%3AGo1.12.16+label%3ACherryPickApproved

- X.509 certificate validation bypass on Windows 10
  A Windows vulnerability allows attackers to spoof valid certificate chains when
  the system root store is in use. These releases include a mitigation for Go
  applications, but it’s strongly recommended that affected users install the
  Windows security update to protect their system.
  This issue is CVE-2020-0601 and Go issue golang.org/issue/36834.
- Panic in crypto/x509 certificate parsing and golang.org/x/crypto/cryptobyte
  On 32-bit architectures, a malformed input to crypto/x509 or the ASN.1 parsing
  functions of golang.org/x/crypto/cryptobyte can lead to a panic.
  The malformed certificate can be delivered via a crypto/tls connection to a
  client, or to a server that accepts client certificates. net/http clients can
  be made to crash by an HTTPS server, while net/http servers that accept client
  certificates will recover the panic and are unaffected.
  Thanks to Project Wycheproof for providing the test cases that led to the
  discovery of this issue. The issue is CVE-2020-7919 and Go issue golang.org/issue/36837.
  This is also fixed in version v0.0.0-20200124225646-8b5121be2f68 of golang.org/x/crypto/cryptobyte.

Signed-off-by: Sebastiaan van Stijn <[email protected]>
(cherry picked from commit 44b5bac)
Signed-off-by: Sebastiaan van Stijn <[email protected]>
@thaJeztah
[release/1.3] vendor: update golang.org/x/crypto 69ecbb4d6d5dab05e491…
14d166c 
…61c6e77ea40a030884e1

full diff: golang/crypto@5c40567...69ecbb4

Includes golang/crypto@69ecbb4
(forward-port of golang/crypto@8b5121b),
which fixes CVE-2020-7919:

Panic in crypto/x509 certificate parsing and golang.org/x/crypto/cryptobyte
On 32-bit architectures, a malformed input to crypto/x509 or the ASN.1 parsing
functions of golang.org/x/crypto/cryptobyte can lead to a panic.
The malformed certificate can be delivered via a crypto/tls connection to a
client, or to a server that accepts client certificates. net/http clients can
be made to crash by an HTTPS server, while net/http servers that accept client
certificates will recover the panic and are unaffected.
Thanks to Project Wycheproof for providing the test cases that led to the
discovery of this issue. The issue is CVE-2020-7919 and Go issue golang.org/issue/36837.

Signed-off-by: Sebastiaan van Stijn <[email protected]>
@theopenlab-ci
Copy link
Copy Markdown

theopenlab-ci Bot commented Jan 28, 2020

Build succeeded.

@fuweid
Copy link
Copy Markdown
Member

fuweid commented Jan 29, 2020 

--- FAIL: TestLosetup (0.14s)
    --- FAIL: TestLosetup/RemoveLoopDevicesAssociatedWithImage (0.05s)
        losetup_test.go:90: assertion failed: error is not nil: losetup --detach /dev/loop4
            error: losetup: /dev/loop4: detach failed: No such device or address
            
            : exit status 1
FAIL
coverage: 88.0% of statements

flaky case?

@fuweid
Copy link
Copy Markdown
Member

fuweid commented Jan 29, 2020 

.docker.io/v2/library/busybox/blobs/sha256:0b89293f3021a122b1d431519677a4fd2ed67cf3098402f57c3a5c0d0e4c2731"
    image_test.go:220: Expected actual usage to equal manifest reported usage of 9466142: got 10767844
FAIL

other weird failure which I meet twice.

@thaJeztah
Copy link
Copy Markdown
Member Author

thaJeztah commented Jan 29, 2020

That failure is in this line; https://github.com/containerd/containerd/blob/v1.3.2/image_test.go#L220
Looking at the history for that file on master, there has been one PR merged; #3832
Not sure if that one would help with the flakiness because it's in a different test (unless artefacts of that test could cause side-effects)

@thaJeztah
Copy link
Copy Markdown
Member Author

thaJeztah commented Jan 29, 2020

It's green now though 🎉 💚

fuweid
fuweid approved these changes Jan 29, 2020
View reviewed changes
Copy link
Copy Markdown
Member

@fuweid fuweid left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@dims
Copy link
Copy Markdown
Member

dims commented Jan 29, 2020

🚢 it!

LGTM

estesp
estesp approved these changes Jan 29, 2020
View reviewed changes
Copy link
Copy Markdown
Member

@estesp estesp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@estesp estesp merged commit 8366042 into containerd:release/1.3 Jan 29, 2020
@thaJeztah thaJeztah deleted the 1.3_bump_golang_1.12.16 branch January 30, 2020 20:17
@thaJeztah thaJeztah mentioned this pull request Feb 27, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@estesp estesp estesp approved these changes

@fuweid fuweid fuweid approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@thaJeztah @fuweid @dims @estesp