How was Kea DHCP v1.4.0 affected by a security advisory?

The United States Computer Emergency Readiness Team issued a medium-rated security advisory for the open source Kea DHCP server version 1.4.0 for a flaw that could cause memory leakage and result in the failure of memory locations or a crashed server -- potentially enabling a denial-of-service attack. What are the consequences for this vulnerability, and are there any workarounds for it?

Kea is an open source Dynamic Host Configuration Protocol (DHCP) server published by the Internet Systems Consortium (ISC). Earlier this year, US-CERT issued a security advisory warning that Kea DHCP 1.4.0 has a memory leak vulnerability that a remote attacker could exploit to cause a denial-of-service attack.

The vulnerability was introduced in the hooks extension of Kea, which enables developers to load third-party libraries that can extract information from the server or even change how the server behaves. The vulnerability is related to the way the Kea 1.4.0 server manages memory when it encounters multiple simultaneous requests; in those cases, the available memory can be exhausted, causing a server failure.

While the ISC security advisory offers some workarounds for this vulnerability -- which can be exploited by attackers capable of sending DHCP traffic to the servers -- it can be mitigated by upgrading to Kea version 1.4.0-P1. It should also be noted that the vulnerability is exploitable only if the Kea DHCP server uses the hooks extension.

If the upgraded version cannot be installed immediately for some reason, the ISC offered some workarounds to limit the threat:

• For some production environments, regular monitoring -- and periodic restarts -- of Kea DHCPv4 and DHCPv6 may effectively mitigate the flaw.
• Running Kea DHCP servers without the hooks extension that enables the attack is also a solution, but only in cases where the production environment does not need to use hooks.
• In some production environments, reverting to Kea DHCP v1.3.0 may be an effective workaround. But before operators attempt to roll back, they should consider the differences in the database schema, which consists of the different tables and the relationships between them. If part of memfile storage is used, the 1.3.0 schema will not be compatible with the 1.4.0 schema -- all of the memfile storage must be used.

If a database solution is being used to track hosts and the assigned IP address leases, the database schemas may not be compatible. In that case, a backup of the previous version of a database must be used to restore it, and the backup database cannot include the version 1.4.0 upgrades. Users are advised to contact ISC for information on using version 1.3.0 without restoring a previous version of a database.

Ask the expert:
Want to ask Judith Myerson a question about security? Submit your question now via email. (All questions are anonymous.)