Описание
When base64 data is split up in pieces, of 3 character or less, tokens were incorrectly calculated to produce 0 bytes. This enables attackers to overwrite the stack with up to 64K of attacker controlled data. Zone files which are written out by NSD itself, such as for zones for which the NSD instance is secondary, will not be formatted like this. The zone file must be fed to NSD directly, (but it could come, for example, from an operator controlled provisioning system).
A flaw was found in NSD (Name Server Daemon). When parsing DNS zone files containing base64-encoded data formatted in segments of three characters or fewer, NSD incorrectly calculates token sizes, resulting in a stack-based buffer overflow. An attacker who can supply or manipulate a zone file loaded by the server could exploit this flaw to overwrite stack memory with controlled data, potentially achieving arbitrary code execution or causing a Denial of Service (DoS).
Отчет
This vulnerability is rated as Important rather than Moderate due to the potential for arbitrary code execution within the daemon process context, even though exploitation requires loading a specially crafted primary zone configuration. In Red Hat environments, NSD is not distributed as part of core Red Hat Enterprise Linux and is only packaged through Fedora and Extra Packages for Enterprise Linux (EPEL). Additionally, secondary zone records transferred and written directly by the daemon do not trigger this condition, limiting the threat model to scenarios where untrusted or operator-provisioned zone definitions are directly ingested.
Дополнительная информация
Статус:
EPSS
8.8 High
CVSS3
Связанные уязвимости
When base64 data is split up in pieces, of 3 character or less, tokens were incorrectly calculated to produce 0 bytes. This enables attackers to overwrite the stack with up to 64K of attacker controlled data. Zone files which are written out by NSD itself, such as for zones for which the NSD instance is secondary, will not be formatted like this. The zone file must be fed to NSD directly, (but it could come, for example, from an operator controlled provisioning system).
When base64 data is split up in pieces, of 3 character or less, tokens were incorrectly calculated to produce 0 bytes. This enables attackers to overwrite the stack with up to 64K of attacker controlled data. Zone files which are written out by NSD itself, such as for zones for which the NSD instance is secondary, will not be formatted like this. The zone file must be fed to NSD directly, (but it could come, for example, from an operator controlled provisioning system).
When base64 data is split up in pieces, of 3 character or less, tokens ...
When base64 data is split up in pieces, of 3 character or less, tokens were incorrectly calculated to produce 0 bytes. This enables attackers to overwrite the stack with up to 64K of attacker controlled data. Zone files which are written out by NSD itself, such as for zones for which the NSD instance is secondary, will not be formatted like this. The zone file must be fed to NSD directly, (but it could come, for example, from an operator controlled provisioning system).
EPSS
8.8 High
CVSS3