Bug 1773617 (CVE-2019-6477) - CVE-2019-6477 bind: TCP Pipelining doesn't limit TCP clients on a single connection
Summary: CVE-2019-6477 bind: TCP Pipelining doesn't limit TCP clients on a single conn...
Keywords:
Status: NEW
Alias: CVE-2019-6477
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1773838 1773839 1773837 1774827
Blocks: 1773619 1778080
TreeView+ depends on / blocked
 
Reported: 2019-11-18 14:59 UTC by msiddiqu
Modified: 2019-12-26 10:26 UTC (History)
12 users (show)

Fixed In Version: bind 9.11.13, bind 9.14.8, bind 9.15.6
Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in the way bind limited the number of TCP clients that can be connected at any given time. A remote attacker could use one TCP client to send a large number of DNS requests over a single connection, causing exhaustion of the pool of file descriptors available to named, and potentially affecting network connections and the management of files such as log files or zone journal files.
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)
patch against 9.11.13 (4.16 KB, patch)
2019-11-19 04:48 UTC, Huzaifa S. Sidhpurwala
no flags Details | Diff

Description msiddiqu 2019-11-18 14:59:42 UTC
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.

Comment 2 Huzaifa S. Sidhpurwala 2019-11-19 04:20:46 UTC
Acknowledgments:

Name: ISC

Comment 5 Huzaifa S. Sidhpurwala 2019-11-19 04:48:22 UTC
Created attachment 1637475 [details]
patch against 9.11.13

Comment 8 Huzaifa S. Sidhpurwala 2019-11-20 04:16:03 UTC
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.

Comment 9 Huzaifa S. Sidhpurwala 2019-11-20 04:20:44 UTC
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)

Comment 11 Huzaifa S. Sidhpurwala 2019-11-21 04:23:41 UTC
External References:

https://kb.isc.org/docs/cve-2019-6477

Comment 13 Huzaifa S. Sidhpurwala 2019-11-21 04:25:09 UTC
Created bind tracking bugs for this issue:

Affects: fedora-all [bug 1774827]

Comment 18 Huzaifa S. Sidhpurwala 2019-11-29 09:40:00 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.