Vulmon
<!--X-Body-Begin-->
<!--X-User-Header-->
oss-sec
mailing list archives
<!--X-User-Header-End-->
<!--X-TopPNI-->
By Date
By Thread
</form>
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
5 CVEs fixed in Go 1.22.1 and Go 1.21.8, 1 CVE fixed in google.golang.org/protobuf
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
From: Alan Coopersmith <alan.coopersmith () oracle com>
Date: Fri, 8 Mar 2024 13:37:09 -0800
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
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
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
By Date
By Thread
Current thread:
5 CVEs fixed in Go 1.22.1 and Go 1.21.8, 1 CVE fixed in google.golang.org/protobuf Alan Coopersmith (Mar 08)
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->