Toyota — CraftedSignal Threat Feedhttps://feed.craftedsignal.io/vendors/toyota/Trending threats, MITRE ATT&CK coverage, and detection metadata — refreshed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioFri, 01 Nov 2024 12:00:00 +0000go-zserio Unbounded Memory Allocation Vulnerabilityhttps://feed.craftedsignal.io/briefs/2024-11-01-go-zserio-memory-allocation/Fri, 01 Nov 2024 12:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-11-01-go-zserio-memory-allocation/go-zserio versions prior to 0.9.1 are vulnerable to unbounded memory allocation when deserializing data, potentially leading to denial of service.A critical vulnerability exists in the go-zserio library, a tool used for serializing data structures, specifically in versions prior to 0.9.1. The vulnerability stems from how the library handles deserialization of arrays, strings, and byte arrays (blobs). When processing these data types, go-zserio reads a size value directly from the input data stream and uses this value to allocate memory. Because the library trusts the provided size without proper validation, a malicious actor can craft a data file containing an extremely large size value. This causes the go-zserio runtime to allocate an excessive amount of memory, potentially exhausting system resources and resulting in a denial-of-service (DoS) condition. The vulnerable library could be integrated into any application that parses untrusted data using go-zserio.

Attack Chain

  1. Attacker crafts a malicious zserio data file containing an excessively large size value for an array, string, or blob field.
  2. The attacker delivers the malicious data file to a vulnerable application that uses go-zserio for data deserialization. This could be achieved through various means, such as uploading the file to a server, sending it as an attachment, or including it in a network packet.
  3. The vulnerable application receives the malicious data file and attempts to deserialize it using the go-zserio library.
  4. The go-zserio library reads the large size value from the malicious data file.
  5. Based on this untrusted size value, the go-zserio library attempts to allocate a large amount of memory to store the incoming data.
  6. The memory allocation request consumes significant system resources, potentially exhausting available memory.
  7. The system may become unresponsive or crash due to memory exhaustion.
  8. The application experiences a denial-of-service condition, becoming unavailable to legitimate users.

Impact

Successful exploitation of this vulnerability can lead to a denial-of-service condition. The affected application becomes unavailable, impacting business operations and potentially causing data loss or corruption. The severity of the impact depends on the role and importance of the application within the organization’s infrastructure. It is not known how many organizations are affected by this vulnerability.

Recommendation

  • Upgrade to go-zserio version 0.9.1 or later to patch the vulnerability.
  • Implement input validation to check the size of arrays, strings, and blobs before deserialization, preventing excessive memory allocation.
  • Deploy the Sigma rule Detect Suspicious Large Memory Allocation to identify processes allocating unusually large amounts of memory, which may indicate exploitation attempts.
  • Monitor applications that use go-zserio for excessive memory consumption using system monitoring tools.
]]>mediumadvisorymemory-allocationdenial-of-servicego-zserioZserio Runtime Unbounded Memory Allocation Vulnerabilityhttps://feed.craftedsignal.io/briefs/2024-05-zserio-oom/Thu, 02 May 2024 12:00:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-05-zserio-oom/A crafted payload can force memory allocations of up to 16 GB, leading to a denial-of-service condition in applications using the Zserio serialization framework, including those within the automotive Navigation Data Standard (NDS).A critical vulnerability exists within the Zserio runtime library, a serialization framework used in various applications, including the Navigation Data Standard (NDS) for automotive systems. This flaw allows a malicious actor to trigger an unbounded memory allocation by providing a specially crafted input. A payload as small as 4-5 bytes can cause memory allocations of up to 16 GB, resulting in a denial-of-service (DoS) condition due to an out-of-memory (OOM) error. This issue affects Zserio versions 2.18.0 and earlier. The vulnerability stems from insufficient validation of the declared size of data structures during deserialization, leading to excessive memory reservation. Exploitation could disrupt critical systems relying on Zserio, particularly within the automotive sector where NDS is widely deployed.

Attack Chain

  1. An attacker crafts a malicious NDS data payload.
  2. The payload includes a “varsize” field claiming an extremely large size (e.g., 2,147,483,647 bytes).
  3. The vulnerable Zserio runtime attempts to deserialize the payload.
  4. The Array.h or Array.java code calls reserve() or reset() with the attacker-controlled size.
  5. The system attempts to allocate a large block of memory (up to 16 GB), based on the attacker-specified size.
  6. Memory allocation fails, or consumes excessive resources.
  7. The application crashes due to an out-of-memory (OOM) error.
  8. The denial-of-service condition prevents the application from functioning correctly.

Impact

The vulnerability affects applications utilizing the Zserio serialization framework, including the Navigation Data Standard (NDS) used by 43 member companies, including Toyota, BMW, Volkswagen, and Mercedes-Benz. Successful exploitation can lead to a denial-of-service (DoS) condition, potentially impacting millions of cars on the road that rely on NDS for map updates and navigation data. Attack vectors include NDS.Live cloud map updates, map data supply chain compromise, and backend data processing pipelines. On 32-bit automotive ECUs, this could affect ADAS functionality. A 4-byte payload can trigger the allocation of 762MB of memory, and a 5-byte payload triggers an allocation of 16GB, leading to a system crash.

Recommendation

  • Apply the patch available in Zserio version 2.18.1 to remediate the vulnerability (https://github.com/ndsev/zserio/releases/tag/v2.18.1).
  • Implement input validation to ensure that the declared size of data structures during deserialization does not exceed the remaining size of the input stream, as suggested in the advisory.
  • Deploy the Sigma rule Detect Zserio Large Memory Allocation to identify potential exploitation attempts in environments where Zserio is used.
]]>mediumadvisoryzseriodenial-of-servicememory-allocationnds