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 dont 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.
Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Bind | Isc | 9.16.0 (including) | 9.16.37 (excluding) |
| Bind | Isc | 9.18.0 (including) | 9.18.11 (excluding) |
| Bind | Isc | 9.19.0 (including) | 9.19.9 (excluding) |
| Bind | Isc | 9.16.8-s1 (including) | 9.16.8-s1 (including) |
| Bind | Isc | 9.16.11-s1 (including) | 9.16.11-s1 (including) |
| Bind | Isc | 9.16.13-s1 (including) | 9.16.13-s1 (including) |
| Bind | Isc | 9.16.14-s1 (including) | 9.16.14-s1 (including) |
| Bind | Isc | 9.16.21-s1 (including) | 9.16.21-s1 (including) |
| Bind | Isc | 9.16.32-s1 (including) | 9.16.32-s1 (including) |
| Bind | Isc | 9.16.36-s1 (including) | 9.16.36-s1 (including) |
The use of previously-freed memory can have any number of adverse consequences, ranging from the corruption of valid data to the execution of arbitrary code, depending on the instantiation and timing of the flaw. The simplest way data corruption may occur involves the system’s reuse of the freed memory. Use-after-free errors have two common and sometimes overlapping causes:
In this scenario, the memory in question is allocated to another pointer validly at some point after it has been freed. The original pointer to the freed memory is used again and points to somewhere within the new allocation. As the data is changed, it corrupts the validly used memory; this induces undefined behavior in the process. If the newly allocated data happens to hold a class, in C++ for example, various function pointers may be scattered within the heap data. If one of these function pointers is overwritten with an address to valid shellcode, execution of arbitrary code can be achieved.