Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <af57800d-82d3-a5ae-fc53-95295a7c41dd@isc.org>
Date: Wed, 11 Jul 2018 15:44:13 -0800
From: Michael McNally <mcnally@....org>
To: oss-security@...ts.openwall.com
Subject: CVE-2018-5739: ISC Kea 1.4.0 failure to release memory may exhaust
 system resources

Today ISC has disclosed a memory leak in Kea 1.4.0 that is potentially
exploitable as a denial-of-service vector.  Our official disclosure page
can be found at https://kb.isc.org/article/AA-01626 or the content can
be found below.

Kea version 1.4.0-P1 (which corrects the memory leak) was publicly
released today and is available from https://www.isc.org/downloads

Michael McNally
ISC Security Officer

-----

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.

CVE:                 CVE-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@....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 http://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 http://www.isc.org/support/.

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

ISC Security Vulnerability Disclosure Policy:

   Details of our current security advisory policy and practice can
   be found here: https://kb.isc.org/article/AA-00861

This Knowledge Base article https://kb.isc.org/article/AA-01626 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.

(c) 2001-2018 Internet Systems Consortium

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.