Back

HIGH

TCP-pipelined queries can bypass tcp-clients limit

Published Nov 26, 2019

Description

With pipelining enabled each incoming query on a TCP connection requires a similar resource allocation to a query received via UDP or via TCP without pipelining enabled. A client using a TCP-pipelined connection to a server could consume more resources than the server has been provisioned to handle. When a TCP connection with a large number of pipelined queries is closed, the load on the server releasing these multiple resources can cause it to become unresponsive, even for queries that can be answered authoritatively or from cache. (This is most likely to be perceived as an intermittent server problem).

Affected products

Remediation

Vendor solution

Upgrade to the patched release most closely related to your current version of BIND:

BIND 9.11.13 BIND 9.14.8 BIND 9.15.6

BIND Supported Preview Edition is a special feature preview branch of BIND provided to eligible ISC support customers.

BIND 9.11.13-S1

Note that the fix for CVE-2019-6477 addresses only the server memory leak issue. TCP-pipelining may still malfunction by dropping some responses on a TCP connection where a client query pattern generates excessive outstanding queries, but the malfunction will affect that TCP connection alone and will not cause any degradation of service to other clients. An affected client connection might also appear to hang, but will clear when either the client or the server initiates a close or reset and will not remain in that state indefinitely.

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.

Red Hat 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)

Red Hat 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.

References (12)

Change history (0)

No recorded changes yet.

Sources
CVE.org / MITRE
Status PUBLISHED
Assigner isc
Published Nov 26, 2019
Updated Sep 16, 2024
Reserved Jan 16, 2019
NVD
Status Modified
Modified Jun 17, 2026
Red Hat
Severity Moderate
Public date Nov 20, 2019