CVE-2016-2774: An attacker who is allowed to connect to DHCP inter-server communications and control channels can exhaust server resources

[Michael McNally]

CVE:                   CVE-2016-2774
Document Version:      2.0
Posting date:          07 March 2016
Program Impacted:      ISC DHCP

Versions affected:   

   4.1.0->4.1-ESV-R12-P1, 4.2.0->4.2.8, 4.3.0->4.3.3-P1.  Older
   versions may also be affected but are well beyond their end-of-life
   (EOL).  Releases prior to 4.1.0 have not been tested.

Severity:              Medium

Exploitable:     

   Remotely, if remote network connections to the DHCP server's
   control ports (e.g. OMAPI and failover) are permitted.

Description:

   In many cases, the ISC DHCP server does not effectively limit
   the number of simultaneous open TCP connections to the ports the
   server uses for inter-process communications and control.  Because
   of this, a malicious party could interfere with server operation
   by opening (and never closing) a large number of TCP connections
   to the server.

Impact:

   By exploiting this vulnerability an attacker can interfere with
   DHCP server operation.  Exact results are difficult to summarize
   concisely because the effect of an attack varies depending on
   server version, the channel being attacked, and in some operating
   systems on environment settings inherited from the launching
   shell (e.g. "ulimit" settings on per-process open file descriptors)
   but depending on the combination potential undesirable outcomes
   include (but are not necessarily limited to):

    -  The server may deliberately exit after encountering an INSIST
       failure (server version dependent).  
    -  The server may become unresponsive and stop answering client requests.
    -  The server may continue operating but not be able to accept further
       connections from OMAPI clients or failover peers.
    -  If no limits are inherited from the environment, the server may
       consume all available sockets, potentially interfering with other
       services running on the same machine.

   Risk of exploitation is highest on the OMAPI port (if OMAPI is
   configured).  The failover code will close incoming connections
   if they are not received from a peer (making it more difficult
   but not impossible to attack a server using failover channels).
   OMAPI, however, has no logic in the server limiting addresses
   from which it will accept connections.  A firewall is recommended
   as an industry-standard precaution against accepting connections
   from untrusted hosts.

CVSS Score:            5.7
CVSS Vector:           (AV:A/AC:M/Au:N/C:N/I:N/A:C)

For more information on the Common Vulnerability Scoring System and
to obtain your specific environmental score please visit:
http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2&vector=(AV:A/AC:M/Au:N/C:N/I:N/A:C)

Workarounds:

   ISC recommends that server operators restrict the hosts allowed
   to make connections to DHCP server inter-process communication
   channels to trusted hosts, blocking connections to the OMAPI
   control port and the failover communications ports from all other
   hosts.

   If OMAPI and/or failover are not being actively used, they can
   be disabled. The ISC Knowledge Base contains some information
   that operators may find relevant:

    -  https://kb.isc.org/article/AA-01355/56/Securing-dhcpd-against-unauthorised-OMAPI-control-connections.html
    -  https://kb.isc.org/article/AA-01356/56/What-is-DHCP-Failover.html
    -  https://kb.isc.org/article/AA-00502/31/A-Basic-Guide-to-Configuring-DHCP-Failover.html

   Additionally, in environments where per-process file descriptor
   limits can be inherited from the shell used to launch dhcpd,
   using ulimit to set a reasonable limit on simultaneous socket
   connections can prevent the INSIST assertion failure outcome but
   may still allow interference with legitimate interprocess
   communication traffic.

Active exploits:

   No known active exploits, but a public mention of the issue has
   occurred on an open mailing list.

Solution: 

   Mitigation code which will make this vulnerability harder to
   exploit will be added to the upcoming DHCP maintenance releases
   (DHCP 4.1-ESV-R13, DHCP 4.3.4, due to be released in March 2016.)

   However, the strategies described in the "Workarounds" section
   of this document are effective and can prevent exploitation of
   the vulnerability.  Unless server operators have identified
   operational needs unique to their environment which conflict
   with this advice, ISC recommends blocking incoming TCP connections
   from untrusted hosts as a preferred strategy.

Acknowledgements:

   ISC would like to thank Konstantin Orekhov for discovering this
   vulnerability.

Document Revision History:

   1.0 Advance Notification 04 March 2016
   2.0 Public Disclosure 07 March 2016

If you'd like more information on ISC Subscription Support and
Advance Security Notifications, please visit http://www.isc.org/support/.

Do you still have questions?  Questions regarding this advisory
should go to security-officer at isc.org.  To report a new issue,
please encrypt your message using security-officer at isc.org's PGP
key which can be found here:

   https://www.isc.org/downloads/software-support-policy/openpgp-key/.

If you are unable to use encrypted email, you may also report new
issues at: https://www.isc.org/community/report-bug/.

Note:

   ISC patches only currently supported versions. When possible we
   indicate EOL versions affected.  (For current information on
   which versions are actively supported, please see
   http://www.isc.org/downloads/).

ISC Security Vulnerability Disclosure Policy:

   Details of our current security advisory policy and practice can
   be found here:
   https://kb.isc.org/article/AA-00861/164/Vulnerability-Disclosure-Policy.html

This Knowledge Base article https://kb.isc.org/article/AA-01354 is
the complete and official security advisory document.

Legal Disclaimer:

   Internet Systems Consortium (ISC) is providing this notice on
   an "AS IS" basis. No warranty or guarantee of any kind is expressed
   in this notice and none should be implied. ISC expressly excludes
   and disclaims any warranties regarding this notice or materials
   referred to in this notice, including, without limitation, any
   implied warranty of merchantability, fitness for a particular
   purpose, absence of hidden defects, or of non-infringement. Your
   use or reliance on this notice or materials referred to in this
   notice is at your own risk. ISC may change this notice at any
   time.  A stand-alone copy or paraphrase of the text of this
   document that omits the document URL is an uncontrolled copy.
   Uncontrolled copies may lack important information, be out of
   date, or contain factual errors.

(c) 2001-2016 Internet Systems Consortium