Using a specially-crafted message, an attacker may potentially cause a BIND server to reach an inconsistent state if the attacker knows (or successfully guesses) the name of a TSIG key used by the server. Since BIND, by default, configures a local session key even on servers whose configuration does not otherwise make use of it, almost all current BIND servers are vulnerable. In releases of BIND dating from March 2018 and after, an assertion check in tsig.c detects this inconsistent state and deliberately exits. Prior to the introduction of the check the server would continue operating in an inconsistent state, with potentially harmful results.
The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Bind | Isc | 9.0.0 (including) | 9.11.18 (including) |
| Bind | Isc | 9.12.0 (including) | 9.12.4 (including) |
| Bind | Isc | 9.13.0 (including) | 9.13.7 (including) |
| Bind | Isc | 9.14.0 (including) | 9.14.11 (including) |
| Bind | Isc | 9.15.0 (including) | 9.15.6 (including) |
| Bind | Isc | 9.16.0 (including) | 9.16.2 (including) |
| Bind | Isc | 9.17.0 (including) | 9.17.1 (including) |
| Bind | Isc | 9.12.4-p1 (including) | 9.12.4-p1 (including) |
| Bind | Isc | 9.12.4-p2 (including) | 9.12.4-p2 (including) |
While assertion is good for catching logic errors and reducing the chances of reaching more serious vulnerability conditions, it can still lead to a denial of service. For example, if a server handles multiple simultaneous connections, and an assert() occurs in one single connection that causes all other connections to be dropped, this is a reachable assertion that leads to a denial of service.