Headline
Red Hat Security Advisory 2024-4848-03
Red Hat Security Advisory 2024-4848-03 - Red Hat OpenShift Container Platform release 4.13.46 is now available with updates to packages and images that fix several bugs and add enhancements. Issues addressed include deserialization and memory exhaustion vulnerabilities.
The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_4848.jsonRed Hat officially shut down their mailing list notifications October 10, 2023. Due to this, Packet Storm has recreated the below data as a reference point to raise awareness. It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.- Packet Storm Staff====================================================================Red Hat Security AdvisorySynopsis: Important: OpenShift Container Platform 4.13.46 security updateAdvisory ID: RHSA-2024:4848-03Product: Red Hat OpenShift EnterpriseAdvisory URL: https://access.redhat.com/errata/RHSA-2024:4848Issue date: 2024-07-31Revision: 03CVE Names: CVE-2024-37298====================================================================Summary: Red Hat OpenShift Container Platform release 4.13.46 is now available with updates to packages and images that fix several bugs and add enhancements.This release includes a security update for Red Hat OpenShift Container Platform 4.13.Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.Description:Red Hat OpenShift Container Platform is Red Hat's cloud computingKubernetes application platform solution designed for on-premise or privatecloud deployments.Security Fix(es):* gorilla/schema: Potential memory exhaustion attack due to sparse slicedeserialization (CVE-2024-37298)For more details about the security issue(s), including the impact, a CVSSscore, acknowledgments, and other related information, refer to the CVEpage(s)listed in the References section.Solution:https://docs.openshift.com/container-platform/4.13/release_notes/ocp-4-13-release-notes.htmlCVEs:CVE-2024-37298References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2294000https://bugzilla.redhat.com/show_bug.cgi?id=2295010Related news
Red Hat Security Advisory 2024-6054-03 - Updated images are now available for Red Hat Advanced Cluster Security. The updated image includes security and bug fixes. Issues addressed include deserialization and memory exhaustion vulnerabilities.
Red Hat Security Advisory 2024-5194-03 - An update for the container-tools:rhel8 module is now available for Red Hat Enterprise Linux 8.8 Extended Update Support. Issues addressed include deserialization and memory exhaustion vulnerabilities.
Red Hat Security Advisory 2024-4858-03 - Red Hat OpenShift Container Platform release 4.16.5 is now available with updates to packages and images that fix several bugs and add enhancements. Issues addressed include deserialization and memory exhaustion vulnerabilities.
Red Hat Security Advisory 2024-4825-03 - An update for podman is now available for Red Hat Enterprise Linux 9.0 Update Services for SAP Solutions. Issues addressed include deserialization and memory exhaustion vulnerabilities.
### Details Running `schema.Decoder.Decode()` on a struct that has a field of type `[]struct{...}` opens it up to malicious attacks regarding memory allocations, taking advantage of the sparse slice functionality. For instance, in the Proof of Concept written below, someone can specify to set a field of the billionth element and it will allocate all other elements before it in the slice. In the local environment environment for my project, I was able to call an endpoint like `/innocent_endpoint?arr.10000000.X=1` and freeze my system from the memory allocation while parsing `r.Form`. I think [this line](https://github.com/gorilla/schema/blob/main/decoder.go#L223) is responsible for allocating the slice, although I haven't tested to make sure, so it's just an educated guess. ### Proof of Concept The following proof of concept works on both v1.2.0 and v1.2.1. I have not tested earlier versions. ```go package main import ( "fmt" "github.com/gorilla/schema" ) func main() { dec :=...