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
Acknowledgments: Name: ISC
Created dhcp tracking bugs for this issue: Affects: fedora-all [bug 1315614]
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]
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.
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.
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.
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.
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