[<prev] [next>] [day] [month] [year] [list]
Date: Fri, 8 Mar 2024 13:37:09 -0800
From: Alan Coopersmith <alan.coopersmith@...cle.com>
To: oss-security@...ts.openwall.com
Subject: 5 CVEs fixed in Go 1.22.1 and Go 1.21.8, 1 CVE fixed in
google.golang.org/protobuf
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@...cle.com
Oracle Solaris Engineering - https://blogs.oracle.com/solaris
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
