cvrf2cusa/cvrf/2023/cvrf-openEuler-SA-2023-1192.xml
Jia Chao 0b34274085 git mv
Signed-off-by: Jia Chao <jiac13@chinaunicom.cn>
2024-07-25 09:57:37 +08:00

199 lines
15 KiB
XML

<?xml version="1.0" encoding="UTF-8"?>
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
<DocumentTitle xml:lang="en">An update for golang is now available for openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP3,openEuler-22.03-LTS and openEuler-22.03-LTS-SP1</DocumentTitle>
<DocumentType>Security Advisory</DocumentType>
<DocumentPublisher Type="Vendor">
<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
<IssuingAuthority>openEuler security committee</IssuingAuthority>
</DocumentPublisher>
<DocumentTracking>
<Identification>
<ID>openEuler-SA-2023-1192</ID>
</Identification>
<Status>Final</Status>
<Version>1.0</Version>
<RevisionHistory>
<Revision>
<Number>1.0</Number>
<Date>2023-03-31</Date>
<Description>Initial</Description>
</Revision>
</RevisionHistory>
<InitialReleaseDate>2023-03-31</InitialReleaseDate>
<CurrentReleaseDate>2023-03-31</CurrentReleaseDate>
<Generator>
<Engine>openEuler SA Tool V1.0</Engine>
<Date>2023-03-31</Date>
</Generator>
</DocumentTracking>
<DocumentNotes>
<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">golang security update</Note>
<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for golang is now available for openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP3,openEuler-22.03-LTS and openEuler-22.03-LTS-SP1.</Note>
<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Go Programming Language.
Security Fix(es):
A maliciously crafted HTTP/2 stream could cause excessive CPU consumption in the HPACK decoder, sufficient to cause a denial of service from a small number of small requests.(CVE-2022-41723)
Large handshake records may cause panics in crypto/tls. Both clients and servers may send large TLS handshake records which cause servers and clients, respectively, to panic when attempting to construct responses. This affects all TLS 1.3 clients, TLS 1.2 clients which explicitly enable session resumption (by setting Config.ClientSessionCache to a non-nil value), and TLS 1.3 servers which request client certificates (by setting Config.ClientAuth &gt;= RequestClientCert).(CVE-2022-41724)
A denial of service is possible from excessive resource consumption in net/http and mime/multipart. Multipart form parsing with mime/multipart.Reader.ReadForm can consume largely unlimited amounts of memory and disk files. This also affects form parsing in the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. ReadForm takes a maxMemory parameter, and is documented as storing &quot;up to maxMemory bytes +10MB (reserved for non-file parts) in memory&quot;. File parts which cannot be stored in memory are stored on disk in temporary files. The unconfigurable 10MB reserved for non-file parts is excessively large and can potentially open a denial of service vector on its own. However, ReadForm did not properly account for all memory consumed by a parsed form, such as map entry overhead, part names, and MIME headers, permitting a maliciously crafted form to consume well over 10MB. In addition, ReadForm contained no limit on the number of disk files created, permitting a relatively small request body to create a large number of disk temporary files. With fix, ReadForm now properly accounts for various forms of memory overhead, and should now stay within its documented limit of 10MB + maxMemory bytes of memory consumption. Users should still be aware that this limit is high and may still be hazardous. In addition, ReadForm now creates at most one on-disk temporary file, combining multiple form parts into a single temporary file. The mime/multipart.File interface type&apos;s documentation states, &quot;If stored on disk, the File&apos;s underlying concrete type will be an *os.File.&quot;. This is no longer the case when a form contains more than one file part, due to this coalescing of parts into a single file. The previous behavior of using distinct files for each form part may be reenabled with the environment variable GODEBUG=multipartfiles=distinct. Users should be aware that multipart.ReadForm and the http.Request methods that call it do not limit the amount of disk consumed by temporary files. Callers can limit the size of form data with http.MaxBytesReader.(CVE-2022-41725)</Note>
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for golang is now available for openEuler-20.03-LTS-SP1,openEuler-20.03-LTS-SP3,openEuler-22.03-LTS and openEuler-22.03-LTS-SP1.
openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">High</Note>
<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">golang</Note>
</DocumentNotes>
<DocumentReferences>
<Reference Type="Self">
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2023-1192</URL>
</Reference>
<Reference Type="openEuler CVE">
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-41723</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-41724</URL>
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-41725</URL>
</Reference>
<Reference Type="Other">
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-41723</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-41724</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-41725</URL>
</Reference>
</DocumentReferences>
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
<Branch Type="Product Name" Name="openEuler">
<FullProductName ProductID="openEuler-20.03-LTS-SP1" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">openEuler-20.03-LTS-SP1</FullProductName>
<FullProductName ProductID="openEuler-20.03-LTS-SP3" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP3">openEuler-20.03-LTS-SP3</FullProductName>
<FullProductName ProductID="openEuler-22.03-LTS" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">openEuler-22.03-LTS</FullProductName>
<FullProductName ProductID="openEuler-22.03-LTS-SP1" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">openEuler-22.03-LTS-SP1</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="aarch64">
<FullProductName ProductID="golang-1.15.7-24" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">golang-1.15.7-24.oe1.aarch64.rpm</FullProductName>
<FullProductName ProductID="golang-1.15.7-24" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP3">golang-1.15.7-24.oe1.aarch64.rpm</FullProductName>
<FullProductName ProductID="golang-1.17.3-15" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">golang-1.17.3-15.oe2203.aarch64.rpm</FullProductName>
<FullProductName ProductID="golang-1.17.3-15" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">golang-1.17.3-15.oe2203sp1.aarch64.rpm</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="noarch">
<FullProductName ProductID="golang-help-1.15.7-24" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">golang-help-1.15.7-24.oe1.noarch.rpm</FullProductName>
<FullProductName ProductID="golang-devel-1.15.7-24" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">golang-devel-1.15.7-24.oe1.noarch.rpm</FullProductName>
<FullProductName ProductID="golang-devel-1.15.7-24" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP3">golang-devel-1.15.7-24.oe1.noarch.rpm</FullProductName>
<FullProductName ProductID="golang-help-1.15.7-24" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP3">golang-help-1.15.7-24.oe1.noarch.rpm</FullProductName>
<FullProductName ProductID="golang-devel-1.17.3-15" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">golang-devel-1.17.3-15.oe2203.noarch.rpm</FullProductName>
<FullProductName ProductID="golang-help-1.17.3-15" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">golang-help-1.17.3-15.oe2203.noarch.rpm</FullProductName>
<FullProductName ProductID="golang-devel-1.17.3-15" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">golang-devel-1.17.3-15.oe2203sp1.noarch.rpm</FullProductName>
<FullProductName ProductID="golang-help-1.17.3-15" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">golang-help-1.17.3-15.oe2203sp1.noarch.rpm</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="src">
<FullProductName ProductID="golang-1.15.7-24" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">golang-1.15.7-24.oe1.src.rpm</FullProductName>
<FullProductName ProductID="golang-1.15.7-24" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP3">golang-1.15.7-24.oe1.src.rpm</FullProductName>
<FullProductName ProductID="golang-1.17.3-15" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">golang-1.17.3-15.oe2203.src.rpm</FullProductName>
<FullProductName ProductID="golang-1.17.3-15" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">golang-1.17.3-15.oe2203sp1.src.rpm</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="x86_64">
<FullProductName ProductID="golang-1.15.7-24" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP1">golang-1.15.7-24.oe1.x86_64.rpm</FullProductName>
<FullProductName ProductID="golang-1.15.7-24" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP3">golang-1.15.7-24.oe1.x86_64.rpm</FullProductName>
<FullProductName ProductID="golang-1.17.3-15" CPE="cpe:/a:openEuler:openEuler:22.03-LTS">golang-1.17.3-15.oe2203.x86_64.rpm</FullProductName>
<FullProductName ProductID="golang-1.17.3-15" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">golang-1.17.3-15.oe2203sp1.x86_64.rpm</FullProductName>
</Branch>
</ProductTree>
<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">A maliciously crafted HTTP/2 stream could cause excessive CPU consumption in the HPACK decoder, sufficient to cause a denial of service from a small number of small requests.</Note>
</Notes>
<ReleaseDate>2023-03-31</ReleaseDate>
<CVE>CVE-2022-41723</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
<ProductID>openEuler-20.03-LTS-SP3</ProductID>
<ProductID>openEuler-22.03-LTS</ProductID>
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>High</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>7.5</BaseScore>
<Vector>AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>golang security update</Description>
<DATE>2023-03-31</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2023-1192</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="2" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="2" xml:lang="en">Large handshake records may cause panics in crypto/tls. Both clients and servers may send large TLS handshake records which cause servers and clients, respectively, to panic when attempting to construct responses. This affects all TLS 1.3 clients, TLS 1.2 clients which explicitly enable session resumption (by setting Config.ClientSessionCache to a non-nil value), and TLS 1.3 servers which request client certificates (by setting Config.ClientAuth &gt;= RequestClientCert).</Note>
</Notes>
<ReleaseDate>2023-03-31</ReleaseDate>
<CVE>CVE-2022-41724</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
<ProductID>openEuler-20.03-LTS-SP3</ProductID>
<ProductID>openEuler-22.03-LTS</ProductID>
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>High</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>7.5</BaseScore>
<Vector>AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>golang security update</Description>
<DATE>2023-03-31</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2023-1192</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="3" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
<Notes>
<Note Title="Vulnerability Description" Type="General" Ordinal="3" xml:lang="en">A denial of service is possible from excessive resource consumption in net/http and mime/multipart. Multipart form parsing with mime/multipart.Reader.ReadForm can consume largely unlimited amounts of memory and disk files. This also affects form parsing in the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. ReadForm takes a maxMemory parameter, and is documented as storing up to maxMemory bytes +10MB (reserved for non-file parts) in memory . File parts which cannot be stored in memory are stored on disk in temporary files. The unconfigurable 10MB reserved for non-file parts is excessively large and can potentially open a denial of service vector on its own. However, ReadForm did not properly account for all memory consumed by a parsed form, such as map entry overhead, part names, and MIME headers, permitting a maliciously crafted form to consume well over 10MB. In addition, ReadForm contained no limit on the number of disk files created, permitting a relatively small request body to create a large number of disk temporary files. With fix, ReadForm now properly accounts for various forms of memory overhead, and should now stay within its documented limit of 10MB + maxMemory bytes of memory consumption. Users should still be aware that this limit is high and may still be hazardous. In addition, ReadForm now creates at most one on-disk temporary file, combining multiple form parts into a single temporary file. The mime/multipart.File interface type s documentation states, If stored on disk, the File s underlying concrete type will be an *os.File. . This is no longer the case when a form contains more than one file part, due to this coalescing of parts into a single file. The previous behavior of using distinct files for each form part may be reenabled with the environment variable GODEBUG=multipartfiles=distinct. Users should be aware that multipart.ReadForm and the http.Request methods that call it do not limit the amount of disk consumed by temporary files. Callers can limit the size of form data with http.MaxBytesReader.</Note>
</Notes>
<ReleaseDate>2023-03-31</ReleaseDate>
<CVE>CVE-2022-41725</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP1</ProductID>
<ProductID>openEuler-20.03-LTS-SP3</ProductID>
<ProductID>openEuler-22.03-LTS</ProductID>
<ProductID>openEuler-22.03-LTS-SP1</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>High</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>7.5</BaseScore>
<Vector>AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>golang security update</Description>
<DATE>2023-03-31</DATE>
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2023-1192</URL>
</Remediation>
</Remediations>
</Vulnerability>
</cvrfdoc>