net-http/mime-multipart on Go resource consumption

Summaryinfo

A vulnerability categorized as problematic has been discovered in net-http and mime-multipart on Go. The affected element is an unknown function. The manipulation results in resource consumption. This vulnerability is cataloged as CVE-2022-41725. There is no exploit available.

Detailsinfo

A vulnerability was found in net-http and mime-multipart on Go (affected version unknown). It has been classified as problematic. Affected is an unknown functionality. The manipulation with an unknown input leads to a resource consumption vulnerability. CWE is classifying the issue as CWE-400. The product does not properly control the allocation and maintenance of a limited resource, thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources. This is going to have an impact on availability. CVE summarizes:

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.

The weakness was shared 02/28/2023. The advisory is shared for download at go.dev. This vulnerability is traded as CVE-2022-41725 since 09/28/2022. There are neither technical details nor an exploit publicly available.

The vulnerability scanner Nessus provides a plugin with the ID 211363 (Ubuntu 22.04 LTS : Go vulnerabilities (USN-7111-1)), which helps to determine the existence of the flaw in a target environment.

There is no information about possible countermeasures known. It may be suggested to replace the affected object with an alternative product.

The vulnerability is also documented in the databases at Tenable (211363) and CERT Bund (WID-SEC-2023-1141). Once again VulDB remains the best source for vulnerability data.

Affected

• Amazon Linux 2
• Red Hat Enterprise Linux
• Gentoo Linux
• Red Hat OpenShift
• RESF Rocky Linux

Productinfo

Name

• mime-multipart
• net-http

CPE 2.3info

• 🔍
• 🔍
• 🔍

CPE 2.2info

• 🔍
• 🔍
• 🔍

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion