CVE-2018-5739: ISC Kea 1.4.0 failure to release memory may exhaust system resources
  • 06 Sep 2018
  • 4 Minutes to read
  • Contributors
  • Dark
    Light
  • PDF

CVE-2018-5739: ISC Kea 1.4.0 failure to release memory may exhaust system resources

  • Dark
    Light
  • PDF

Article Summary

Kea DHCP 1.4.0 may fail to release memory after temporarily storing client network packets.  This causes a constant increase in memory consumption that can cause server resources to become exhausted, leading to loss of DHCP server functionality.

CVECVE-2018-5739

Document Version: 2.0

Posting date: 11 July 2018

Program Impacted: Kea DHCP

Versions affected: 1.4.0

Severity: Medium

Exploitable: From adjacent networks permitted to relay DHCP traffic to the Kea server

Description:

An extension to hooks capabilities which debuted in Kea 1.4.0 introduced a memory leak for operators who are using certain hooks library facilities. In order to support multiple requests simultaneously, Kea 1.4 added a callout handle store but unfortunately the initial implementation of this store does not properly free memory in every case.  Hooks which make use of query4 or query6 parameters in their callouts can leak memory, resulting in the eventual exhaustion of available memory and subsequent failure of the server process.

Impact:

Only servers using hooks which make use of the callout handle store are affected.  A Kea server which is using one or more hooks libraries that exhibit this problem will increase its memory use over time, with the rate of increase being proportional to the amount of DHCP traffic processed.  Eventually, due to uncontrolled growth, the server will either exhaust all system memory or, if the administrator has set a per-process memory limit, will hit that limit, after which point further memory allocations will fail and the Kea server will crash. 

An attacker who is within the broadcast domain of the Kea server or in a network which is permitted to relay DHCP traffic to the Kea server can hasten the arrival of this outcome by deliberately sending a large volume of requests to the Kea server.

Ability to deliberately trigger this vulnerability depends on the hooks libraries used and the hook points used for callouts.  Our scoring for this vulnerability is based on the hook points used for hook libraries distributed by ISC and also based on the assumption that the Kea server does not accept arbitrary traffic from the internet (but is protected, e.g. by firewall, and only accepts DHCP traffic from the local broadcast domain and from nearby networks via authorized DHCP relay agents.)  We cannot score every combination, but the risk could be higher to custom-developed hook libraries using other hook points or to servers which accept arbitrary DHCP traffic without restriction.

CVSS Score:   6.5, or 4.3 if a supervising process will restart the Kea server if it terminates.

CVSS Vector:   CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

For more information on the Common Vulnerability Scoring System and to obtain your specific environmental score please visit: https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Workarounds:

  • Monitoring and routinely restarting ISC Kea DHCPv4 and DHCPv6 services may be an effective mitigation for some production environments
  • Running a new build of Kea without any hook libraries that use the callout store is another option, though it may not be a viable option where the production environment is dependent on the other hooks that need to be omitted to avoid these symptoms.  These hooks distributed by ISC do not use the callout store and are safe to use:  Lease Commands, Stat Commands, Host Commands (a Kea Premium hook) and Subnet Commands (a subscriber-only hook provided to Kea support customers).
  • Reverting to Kea DHCP 1.3.0 may be possible for some production environments but because of differences in the database schema operators should check carefully before attempting rollback:
    • If using memfile storage entirely, there should not be any compatibility issues.
    • If using a database solution for hosts or leases, the 1.4.0 schema will be incompatible with ISC Kea 1.3.0; the database therefore must be restored from a pre-upgrade backup for this to be successful.
    • If you are unsure whether or not you can roll back to 1.3.0 without restoring a previous version of your database, you may send an e-mail to security-officer@isc.org describing your storage setup and we will advise.

Active exploits:

ISC are not aware of any deliberate exploits of this condition, but even without deliberate exploitation the memory allocations of affected servers will grow over time until memory exhaustion becomes a problem.

Solution:

Upgrade to Kea 1.4.0-P1, available via https://www.isc.org/downloads.

Acknowledgements:   ISC would like to thank Shawn Routhier of Infoblox for making us aware of this issue.

Document Revision History:

1.0 Advance Notification, 29 June 2018
1.1 Corrected description of Subnet Commands hook, 02 July 2018
2.0 Public disclosure, 11 July 2018

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

Do you still have questions?   Questions regarding this advisory should go to security-officer@isc.orgTo report a new issue, please encrypt your message using security-officer@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 https://www.isc.org/downloads/). 

ISC Security Vulnerability Disclosure Policy:   Details of our current security advisory policy and practice can be found in the ISC Software Defect and Security Vulnerability Disclosure Policy.

This Knowledgebase article 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.