CVE-2024-8508

Published Oct 3, 2024

Last updated a year ago

Overview

Description
NLnet Labs Unbound up to and including version 1.21.0 contains a vulnerability when handling replies with very large RRsets that it needs to perform name compression for. Malicious upstreams responses with very large RRsets can cause Unbound to spend a considerable time applying name compression to downstream replies. This can lead to degraded performance and eventually denial of service in well orchestrated attacks. The vulnerability can be exploited by a malicious actor querying Unbound for the specially crafted contents of a malicious zone with very large RRsets. Before Unbound replies to the query it will try to apply name compression which was an unbounded operation that could lock the CPU until the whole packet was complete. Unbound version 1.21.1 introduces a hard limit on the number of name compression calculations it is willing to do per packet. Packets that need more compression will result in semi-compressed packets or truncated packets, even on TCP for huge messages, to avoid locking the CPU for long. This change should not affect normal DNS traffic.
Source
sep@nlnetlabs.nl
NVD status
Analyzed
Products
unbound, debian_linux

Risk scores

CVSS 3.1

Type
Primary
Base score
5.3
Impact score
1.4
Exploitability score
3.9
Vector string
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Severity
MEDIUM

Weaknesses

sep@nlnetlabs.nl
CWE-606
nvd@nist.gov
CWE-1284

Social media

Hype score
Not currently trending

Configurations

  1. Fast DDS is a C++ implementation of the DDS (Data Distribution Service) standard of the OMG (Object Management Group ). ParticipantGenericMessage is the DDS Security control-message container that carries not only the handshake but also on going security-control traffic after the handshake, such as crypto-token exchange, rekeying, re-authentication, and token delivery for newly appearing endpoints. On receive, the CDR parser is invoked first and deserializes the `message_data` (i .e., the `DataHolderSeq`) via the `readParticipantGenericMessage → readDataHolderSeq` path. The `DataHolderSeq` is parsed sequentially: a sequence count (`uint32`), and for each DataHolder the `class_id` string (e.g. `DDS:Auth:PKI-DH:1.0+Req`), string properties (a sequence of key/value pairs), and binary properties (a name plus an octet-vector). The parser operat es at a stateless level and does not know higher-layer state (for example, whether the handshake has already completed), s o it fully unfolds the structure before distinguishing legitimate from malformed traffic. Because RTPS permits duplicates, delays, and retransmissions, a receiver must perform at least minimal structural parsing to check identity and sequence n umbers before discarding or processing a message; the current implementation, however, does not "peek" only at a minimal header and instead parses the entire `DataHolderSeq`. As a result, prior to versions 3.4.1, 3.3.1, and 2.6.11, this parsi ng behavior can trigger an out-of-memory condition and remotely terminate the process. Versions 3.4.1, 3.3.1, and 2.6.11 p atch the issue.CVE-2025-62603