This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1315259 - (CVE-2016-2774) CVE-2016-2774 dhcp: unclosed TCP connections to OMAPI or failover ports can cause DoS
CVE-2016-2774 dhcp: unclosed TCP connections to OMAPI or failover ports can c...
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20160307,repor...
: Security
Depends On: 1315614 1329194
Blocks: 1315262 1323912
  Show dependency treegraph
 
Reported: 2016-03-07 06:49 EST by Adam Mariš
Modified: 2016-11-06 00:19 EDT (History)
7 users (show)

See Also:
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:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adam Mariš 2016-03-07 06:49:23 EST
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:

https://kb.isc.org/article/AA-01354
Comment 1 Adam Mariš 2016-03-07 06:49:29 EST
Acknowledgments:

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

Affects: fedora-all [bug 1315614]
Comment 3 Jiri Popelka 2016-03-10 03:22:54 EST
Upstream commit:
https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=commitdiff;h=0b209ea5cc333255e055113fa2ad636dda681a21

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 10:16:00 EDT
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:

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

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:

https://kb.isc.org/article/AA-01355/56/Securing-dhcpd-against-unauthorised-OMAPI-control-connections.html

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

https://access.redhat.com/solutions/32776

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 14:52:20 EDT
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 07:41:36 EDT
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 16:20:18 EDT
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 16:21:54 EDT
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

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