5 CVEs fixed in Go 1.22.1 and Go 1.21.8, 1 CVE fixed in google.golang.org/protobuf

[Alan Coopersmith <alan.coopersmith () oracle com>]

https://groups.google.com/g/golang-announce/c/5pwGVUPoMbg announces the
releases of Go 1.22.1 and Go 1.21.8 containing fixes for 5 CVEs:

>- crypto/x509: Verify panics on certificates with an unknown public key
>  algorithm
>
>  Verifying a certificate chain which contains a certificate with an
>  unknown public key algorithm will cause Certificate.Verify to panic.
>
>  This affects all crypto/tls clients, and servers that set Config.ClientAuth
>  to VerifyClientCertIfGiven or RequireAndVerifyClientCert. The default
>  behavior is for TLS servers to not verify client certificates.
>
>  Thanks to John Howard (Google) for reporting this issue.
>
>  This is CVE-2024-24783 and Go issue https://go.dev/issue/65390.
>
>- net/http: memory exhaustion in Request.ParseMultipartForm
>
>  When parsing a multipart form (either explicitly with
>  Request.ParseMultipartForm or implicitly with Request.FormValue,
>  Request.PostFormValue, or Request.FormFile), limits on the total size of
>  the parsed form were not applied to the memory consumed while reading a
>  single form line. This permitted a maliciously crafted input containing
>  very long lines to cause allocation of arbitrarily large amounts of memory,
>  potentially leading to memory exhaustion.
>
>  ParseMultipartForm now correctly limits the maximum size of form lines.
>
>  Thanks to Bartek Nowotarski for reporting this issue.
>
>  This is CVE-2023-45290 and Go issue https://go.dev/issue/65383.
>
>- net/http, net/http/cookiejar: incorrect forwarding of sensitive headers
>  and cookies on HTTP redirect
>
>  When following an HTTP redirect to a domain which is not a subdomain match
>  or exact match of the initial domain, an http.Client does not forward
>  sensitive headers such as "Authorization" or "Cookie". For example, a
>  redirect from foo.com to www.foo.com will forward the Authorization header,
>  but a redirect to bar.com will not.
>
>  A maliciously crafted HTTP redirect could cause sensitive headers to be
>  unexpectedly forwarded.
>
>  Thanks to Juho Nurminen of Mattermost for reporting this issue.
>
>  This is CVE-2023-45289 and Go issue https://go.dev/issue/65065.
>
>- html/template: errors returned from MarshalJSON methods may break template
>  escaping
>
>  If errors returned from MarshalJSON methods contain user controlled data,
>  they may be used to break the contextual auto-escaping behavior of the
>  html/template package, allowing for subsequent actions to inject unexpected
>  content into templates.
>
>  Thanks to RyotaK (https://ryotak.net) for reporting this issue.
>
>  This is CVE-2024-24785 and Go issue https://go.dev/issue/65697.
>
>- net/mail: comments in display names are incorrectly handled
>
>  The ParseAddressList function incorrectly handles comments (text within
>  parentheses) within display names. Since this is a misalignment with
>  conforming address parsers, it can result in different trust decisions
>  being made by programs using different parsers.
>
>  Thanks to Juho Nurminen of Mattermost and Slonser
>  (https://github.com/Slonser) for reporting this issue.
>
>  This is CVE-2024-24784 and Go issue https://go.dev/issue/65083.

Separately, one more CVE fix was reported in
https://groups.google.com/g/golang-announce/c/ArQ6CDgtEjY/m/oLMrdq_GBQAJ :

> Version v1.33.0  of the google.golang.org/protobuf module fixes a bug in
> the google.golang.org/protobuf/encoding/protojson package which could cause
> the Unmarshal function to enter an infinite loop when handling some invalid
> inputs. This condition could only occur when unmarshaling into a message
> which contains a google.protobuf.Any value, or when the
> UnmarshalOptions.UnmarshalUnknown option is set. Unmarshal now correctly
> returns an error when handling these inputs.
>
> This is CVE-2024-24786.

Though note the followup message on that page:

> A small correction: This vulnerability applies when the
> UnmarshalOptions.DiscardUnknown option is set (as well as when unmarshaling
> into any message which contains a google.protobuf.Any). There is no
> UnmarshalUnknown option.
>
> In addition, version 1.33.0 of google.golang.org/protobuf inadvertently
> introduced an incompatibility with the older github.com/golang/protobuf
> module. (https://github.com/golang/protobuf/issues/1596) Users of the older
> module should update to https://github.com/golang/protobuf/releases/tag/v1.5.4


--
        -Alan Coopersmith-                 alan.coopersmith () oracle com
         Oracle Solaris Engineering - https://blogs.oracle.com/solaris