Bug 1315259 (CVE-2016-2774)

Summary: CVE-2016-2774 dhcp: unclosed TCP connections to OMAPI or failover ports can cause DoS
Product: [Other] Security Response Reporter: Adam Mariš <amaris>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: carnil, jpopelka, sardella, security-response-team, slawomir, slong, tfrazier
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: dhcp 4.3.4, dhcp 4.1-ESV-R13 Doc Type: Bug Fix
Doc Text:
A resource-consumption flaw was discovered in the DHCP server. dhcpd did not restrict the number of open connections to OMAPI and failover ports. A remote attacker able to establish TCP connections to one of these ports could use this flaw to cause dhcpd to exit unexpectedly, stop responding requests, or exhaust system sockets (denial of service).
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-06-08 02:49:27 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1315614, 1329194    
Bug Blocks: 1315262, 1323912    

Description Adam Mariš 2016-03-07 11:49:23 UTC
It was reported that 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.

As result, the server may deliberately exit after encountering an INSIST failure (server version dependent), or may become unresponsive and stop answering client requests, or 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.

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.

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.

External Reference:


Comment 1 Adam Mariš 2016-03-07 11:49:29 UTC

Name: ISC

Comment 2 Adam Mariš 2016-03-08 08:52:08 UTC
Created dhcp tracking bugs for this issue:

Affects: fedora-all [bug 1315614]

Comment 3 Jiri Popelka 2016-03-10 08:22:54 UTC
Upstream commit:

From 4.3.4b1 announcement:
As mentioned in the recent security annoucement we found an issue
with our handling of exccessive numbers of connections.  While we
beleive the best idea is for people to properly secure their DHCP
severs (disable OMAPI if not in use, use firewalls to limit access
to OMAPI and failove ports and use process limits to restrict the
resources the servers can use) we have added code to limit the number
of connections a server will allow.  We have chosen 200 as the
default number which should be large enough for most configurations.
You may adjust this value by editing includes/site.h and changing
the value of MAX_FD_VALUE.  A value of 0 means unlimited.  We will
be evaluating the connection code in more detail in the future and
may change how this works.  [ISC-Bugs #41845]

Comment 4 Tomas Hoger 2016-03-15 14:16:00 UTC
As noted in the upstream advisory, this issue only affects configuration that either enable OMAPI (Object Management API) port or use DHCP failover.  Neither of those are default or commonly used.

The dhcp packages in Red Hat Enterprise Linux do not include any default configuration, as it is network / deployment specific.  The default dhcpd.conf points users to an example configuration file stored in /usr/share/doc/dhcp*.  Examples included in the dhcp packages do not include any OMAPI or failover configuration.

DHCP failover can be configured between two DHCP servers.  Relevant configuration directive is "failover".  The failover port (647 is the default port reserved for DHCP failover, but dhcpd can be configured to use other port) is only expected to be accessed by the configured failover peer.  Additionally, upstream advisory notes that connections from any other IP than the one configured as failover peer are dropped, making it difficult to exploit this issue using the failover port.  This issue can also be mitigated by configuring firewall / iptables restrictions and only allow access to the failover port from the IP address of the configured failover peer.

ISC / upstream knowledge base articles with basic information about DHCP failover and its configuration:


The OMAPI interface can be used to query or modify status of a running DHCP server.  It is enabled using the "omapi-port" configuration directive.  The default port number is 7911.  If the OMAPI interface is not actively used, it should be disabled.  Otherwise, access to the OMAPI port can be restricted by firewall / iptables configuration.  Typically, only few other trusted hosts need access to OMAPI, such as monitoring or configuration management stations.  If access can not be restricted to few trusted IPs, this issue can be mitigated by limiting the number of connections to the OMAPI port, for example using the connlimit iptables extension.

ISC / upstream knowledge base article with recommendations on how to secure OMAPI interface:


Red Hat knowledge base article with few examples of connlimit use:


As typical dhcpd configurations do not use OMAPI and failover, they are not affected by this issue.  The dhcpd configuration can be checked for the use of "failover" and "omapi-port" directives to detect possibly affected deployments.  Note that when dhcpd configuration is stored in LDAP, it is not sufficient to only search dhcpd.conf file for those directives.  The netstat tool can also be used to check if dhcpd has any open TCP sockets.

Comment 6 Fedora Update System 2016-05-04 18:52:20 UTC
dhcp-4.3.3-9.P1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 7 Fedora Update System 2016-05-07 11:41:36 UTC
dhcp-4.3.4-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Comment 8 Fedora Update System 2016-05-17 20:20:18 UTC
dhcp-4.3.2-8.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.

Comment 10 errata-xmlrpc 2016-11-03 20:21:54 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2016:2590 https://rhn.redhat.com/errata/RHSA-2016-2590.html