As per upstream advisory: By design, BIND is intended to limit the number of TCP clients that can be connected at any given time. The update to this functionality introduced by CVE-2018-5743 changed how BIND calculates the number of concurrent TCP clients from counting the outstanding TCP queries to counting the TCP client connections. On a server with TCP-pipelining capability, it is possible for one TCP client to send a large number of DNS requests over a single connection. Each outstanding query will be handled internally as an independent client request, thus bypassing the new TCP clients limit.
Acknowledgments: Name: ISC
Created attachment 1637475 [details] patch against 9.11.13
Please note the following details about this update, released by upstream: Further testing of the solution and feedback from our partners have highlighted to us that the fix is incomplete in a situation where a TCP-pipelining client is sending queries at an excessive rate, allowing a backlog of outstanding queries to build up. The fix remains effective for protection of server resources in this situation, but a TCP-pipelined connection that sends a high rate of queries may experience a malfunction of the connection. The impact is confined to any clients that are behaving as noted above; service is not degraded on the server for other clients. The malfunction can manifest itself in one of two ways: a) Some client queries are dropped (server sees them as malformed) b) The TCP connection appears to hang A hanging TCP connection will clear when either the client or the server initiates a close or reset. We think that it is unlikely that there are any genuine TCP clients sending high volumes of TCP-pipelined queries; problems reported to ISC have been due solely to malfunctioning clients. Also the majority of DNS client query traffic today is still transported over UDP.
Statement: The patch for CVE-2018-5743 introduced a change in the way bind calculated the number of concurrent connections, from counting the outstanding TCP queries to counting the TCP client connections. However this functionality was not correctly implemented, a attacker could use a single TCP connection to send large number of DNS requests causing denial of service. As per upstream the fix does not help in a situation where a TCP-pipelining client is sending queries at an excessive rate, allowing a backlog of outstanding queries to build up. More details about this is available in the upstream advisory. This bind flaw can be exploited by a remote attacker (AV:N) by opening large number of simultaneous TCP client connections with the server. The attacker needs to use a server which has TCP-pipelining capability to use one TCP connection to send large number of requests. (AC:L and PR:N) No user interaction is required from the server side (UI:N). The attacker can cause denial of service (A:H) by exhausting the file descriptor pool which named has access to. (S:U)
External References: https://kb.isc.org/docs/cve-2019-6477
Created bind tracking bugs for this issue: Affects: fedora-all [bug 1774827]
Mitigation: The vulnerability can be mitigated by disabling server TCP-pipelining: ~~~ keep-response-order { any; }; ~~~ and then restarting BIND. The server restart is necessary because neither a 'reload' nor a 'reconfig' operation will properly reset currently pipelining TCP clients. Disabling TCP-pipelining entirely is completely effective at mitigating the vulnerability with minimal impact to clients that use pipelined TCP connections and with no impact to clients that do not support TCP-pipelining. The majority of Internet client DNS queries are transported over UDP or TCP without use of TCP-pipelining. Note: This mitigation will only work with bind-9.11 and above.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2020:1061 https://access.redhat.com/errata/RHSA-2020:1061
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-6477
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2020:1845 https://access.redhat.com/errata/RHSA-2020:1845