Headline
Red Hat Security Advisory 2024-4825-03
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.
The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_4825.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: podman security updateAdvisory ID: RHSA-2024:4825-03Product: Red Hat Enterprise LinuxAdvisory URL: https://access.redhat.com/errata/RHSA-2024:4825Issue date: 2024-07-24Revision: 03CVE Names: CVE-2024-37298====================================================================Summary: An update for podman is now available for Red Hat Enterprise Linux 9.0 Update Services for SAP Solutions.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:The podman tool manages pods, container images, and containers. It is part of the libpod library, which is for applications that use container pods. Container pods is a concept in Kubernetes.Security Fix(es):* gorilla/schema: Potential memory exhaustion attack due to sparse slice deserialization (CVE-2024-37298)For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://access.redhat.com/articles/11258CVEs:CVE-2024-37298References:https://access.redhat.com/security/updates/classification/#importanthttps://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-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.
### 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 :=...