Описание
Sending a flood of dynamic DNS updates may cause named to allocate large amounts of memory. This, in turn, may cause named to exit due to a lack of free memory. We are not aware of any cases where this has been exploited.
Memory is allocated prior to the checking of access permissions (ACLs) and is retained during the processing of a dynamic update from a client whose access credentials are accepted. Memory allocated to clients that are not permitted to send updates is released immediately upon rejection. The scope of this vulnerability is limited therefore to trusted clients who are permitted to make dynamic zone changes.
If a dynamic update is REFUSED, memory will be released again very quickly. Therefore it is only likely to be possible to degrade or stop named by sending a flood of unaccepted dynamic updates comparable in magnitude to a query flood intended to achieve the same detrimental outcome.
BIND 9.11 and earlier branches are also affected, but through exhaustion of internal resources rather than memory constraints. This may reduce performance but should not be a significant problem for most servers. Therefore we don't intend to address this for BIND versions prior to BIND 9.16.
This issue affects BIND 9 versions 9.16.0 through 9.16.36, 9.18.0 through 9.18.10, 9.19.0 through 9.19.8, and 9.16.8-S1 through 9.16.36-S1.
A flaw was found in Bind, where sending a flood of dynamic DNS updates may cause named to allocate large amounts of memory. This issue may cause named to slow down due to a lack of free memory, resulting in a denial of service (DoS).
Отчет
Exploitation of this vulnerability is limited to trusted clients who are permitted to make dynamic zone changes. The impact on the 'named' service is directly related to the volume of requests being sent in. The service will recover to normal once an attacker stops sending dynamic updates. While a performance impact can be triggered, it is unlikely to result in a crash.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Enterprise Linux 6 | bind | Out of support scope | ||
| Red Hat Enterprise Linux 7 | bind | Will not fix | ||
| Red Hat Enterprise Linux 9 | dhcp | Not affected | ||
| Red Hat Enterprise Linux 8 | bind9.16 | Fixed | RHSA-2023:2792 | 16.05.2023 |
| Red Hat Enterprise Linux 8 | bind | Fixed | RHSA-2023:7177 | 14.11.2023 |
| Red Hat Enterprise Linux 8 | bind | Fixed | RHSA-2023:7177 | 14.11.2023 |
| Red Hat Enterprise Linux 8.6 Extended Update Support | bind | Fixed | RHSA-2024:2720 | 07.05.2024 |
| Red Hat Enterprise Linux 8.6 Extended Update Support | dhcp | Fixed | RHSA-2024:2720 | 07.05.2024 |
| Red Hat Enterprise Linux 8.8 Extended Update Support | bind | Fixed | RHSA-2024:1406 | 19.03.2024 |
| Red Hat Enterprise Linux 9 | bind | Fixed | RHSA-2023:2261 | 09.05.2023 |
Показывать по
Дополнительная информация
Статус:
6.5 Medium
CVSS3
Связанные уязвимости
Sending a flood of dynamic DNS updates may cause `named` to allocate large amounts of memory. This, in turn, may cause `named` to exit due to a lack of free memory. We are not aware of any cases where this has been exploited. Memory is allocated prior to the checking of access permissions (ACLs) and is retained during the processing of a dynamic update from a client whose access credentials are accepted. Memory allocated to clients that are not permitted to send updates is released immediately upon rejection. The scope of this vulnerability is limited therefore to trusted clients who are permitted to make dynamic zone changes. If a dynamic update is REFUSED, memory will be released again very quickly. Therefore it is only likely to be possible to degrade or stop `named` by sending a flood of unaccepted dynamic updates comparable in magnitude to a query flood intended to achieve the same detrimental outcome. BIND 9.11 and earlier branches are also affected, but through exhaustion of ...
Sending a flood of dynamic DNS updates may cause `named` to allocate large amounts of memory. This, in turn, may cause `named` to exit due to a lack of free memory. We are not aware of any cases where this has been exploited. Memory is allocated prior to the checking of access permissions (ACLs) and is retained during the processing of a dynamic update from a client whose access credentials are accepted. Memory allocated to clients that are not permitted to send updates is released immediately upon rejection. The scope of this vulnerability is limited therefore to trusted clients who are permitted to make dynamic zone changes. If a dynamic update is REFUSED, memory will be released again very quickly. Therefore it is only likely to be possible to degrade or stop `named` by sending a flood of unaccepted dynamic updates comparable in magnitude to a query flood intended to achieve the same detrimental outcome. BIND 9.11 and earlier branches are also affected, but through exhaustion of
Sending a flood of dynamic DNS updates may cause `named` to allocate l ...
Sending a flood of dynamic DNS updates may cause `named` to allocate large amounts of memory. This, in turn, may cause `named` to exit due to a lack of free memory. We are not aware of any cases where this has been exploited. Memory is allocated prior to the checking of access permissions (ACLs) and is retained during the processing of a dynamic update from a client whose access credentials are accepted. Memory allocated to clients that are not permitted to send updates is released immediately upon rejection. The scope of this vulnerability is limited therefore to trusted clients who are permitted to make dynamic zone changes. If a dynamic update is REFUSED, memory will be released again very quickly. Therefore it is only likely to be possible to degrade or stop `named` by sending a flood of unaccepted dynamic updates comparable in magnitude to a query flood intended to achieve the same detrimental outcome. BIND 9.11 and earlier branches are also affected, but through exhaustion of ...
6.5 Medium
CVSS3