cve-2018-5739
Vulnerability from cvelistv5
Published
2019-01-16 20:00
Modified
2024-09-17 02:11
Summary
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. Affects Kea DHCP 1.4.0.
Impacted products
Vendor Product Version
Show details on NVD website


{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-05T05:40:51.272Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_refsource_CONFIRM",
              "x_transferred"
            ],
            "url": "https://kb.isc.org/docs/aa-01626"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "Kea DHCP",
          "vendor": "ISC",
          "versions": [
            {
              "status": "affected",
              "version": "Kea DHCP 1.4.0"
            }
          ]
        }
      ],
      "datePublic": "2018-07-11T00:00:00",
      "descriptions": [
        {
          "lang": "en",
          "value": "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. Affects Kea DHCP 1.4.0."
        }
      ],
      "metrics": [
        {
          "cvssV3_0": {
            "attackComplexity": "LOW",
            "attackVector": "ADJACENT_NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 6.5,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.0"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "description": "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. \n\nAn 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.\n\nAbility 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.",
              "lang": "en",
              "type": "text"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2019-01-16T19:57:01",
        "orgId": "404fd4d2-a609-4245-b543-2c944a302a22",
        "shortName": "isc"
      },
      "references": [
        {
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://kb.isc.org/docs/aa-01626"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "value": "Upgrade to Kea 1.4.0-P1 or higher, available via https://www.isc.org/downloads."
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Failure to release memory may exhaust system resources",
      "workarounds": [
        {
          "lang": "en",
          "value": "+  Monitoring and routinely restarting ISC Kea DHCPv4 and DHCPv6 services may be an effective mitigation for some production environments\n  +  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).\n  +  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:\n      -  If using memfile storage entirely, there should not be any compatibility issues.\n      -  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.\n      -  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."
        }
      ],
      "x_legacyV4Record": {
        "CVE_data_meta": {
          "ASSIGNER": "security-officer@isc.org",
          "DATE_PUBLIC": "2018-07-11T00:00:00.000Z",
          "ID": "CVE-2018-5739",
          "STATE": "PUBLIC",
          "TITLE": "Failure to release memory may exhaust system resources"
        },
        "affects": {
          "vendor": {
            "vendor_data": [
              {
                "product": {
                  "product_data": [
                    {
                      "product_name": "Kea DHCP",
                      "version": {
                        "version_data": [
                          {
                            "version_name": "Kea DHCP",
                            "version_value": "1.4.0"
                          }
                        ]
                      }
                    }
                  ]
                },
                "vendor_name": "ISC"
              }
            ]
          }
        },
        "data_format": "MITRE",
        "data_type": "CVE",
        "data_version": "4.0",
        "description": {
          "description_data": [
            {
              "lang": "eng",
              "value": "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. Affects Kea DHCP 1.4.0."
            }
          ]
        },
        "impact": {
          "cvss": {
            "attackComplexity": "LOW",
            "attackVector": "ADJACENT_NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 6.5,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.0"
          }
        },
        "problemtype": {
          "problemtype_data": [
            {
              "description": [
                {
                  "lang": "eng",
                  "value": "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. \n\nAn 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.\n\nAbility 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."
                }
              ]
            }
          ]
        },
        "references": {
          "reference_data": [
            {
              "name": "https://kb.isc.org/docs/aa-01626",
              "refsource": "CONFIRM",
              "url": "https://kb.isc.org/docs/aa-01626"
            }
          ]
        },
        "solution": [
          {
            "lang": "en",
            "value": "Upgrade to Kea 1.4.0-P1 or higher, available via https://www.isc.org/downloads."
          }
        ],
        "source": {
          "discovery": "UNKNOWN"
        },
        "work_around": [
          {
            "lang": "en",
            "value": "+  Monitoring and routinely restarting ISC Kea DHCPv4 and DHCPv6 services may be an effective mitigation for some production environments\n  +  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).\n  +  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:\n      -  If using memfile storage entirely, there should not be any compatibility issues.\n      -  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.\n      -  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."
          }
        ]
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "404fd4d2-a609-4245-b543-2c944a302a22",
    "assignerShortName": "isc",
    "cveId": "CVE-2018-5739",
    "datePublished": "2019-01-16T20:00:00Z",
    "dateReserved": "2018-01-17T00:00:00",
    "dateUpdated": "2024-09-17T02:11:49.386Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2018-5739\",\"sourceIdentifier\":\"security-officer@isc.org\",\"published\":\"2019-01-16T20:29:00.940\",\"lastModified\":\"2024-11-21T04:09:17.420\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"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. Affects Kea DHCP 1.4.0.\"},{\"lang\":\"es\",\"value\":\"Una extensi\u00f3n de las capacidades de enlace que debut\u00f3 en Kea 1.4.0 introdujo una fuga de memoria para los operadores que emplean ciertas caracter\u00edsticas de la biblioteca de enlaces. Para poder soportar m\u00faltiples peticiones de forma simult\u00e1nea, Kea 1.4 introdujo un almac\u00e9n de manejo de llamadas pero, desafortunadamente, la implementaci\u00f3n inicial de este almac\u00e9n no libera memoria correctamente en cada caso. Los enlaces que emplean los par\u00e1metros query4 o query6 en sus llamadas pueden filtrar memoria, lo que resulta en el agotamiento de la memoria disponible y el el subsiguiente error del proceso del servidor. Afecta a Kea DHCP 1.4.0.\"}],\"metrics\":{\"cvssMetricV30\":[{\"source\":\"security-officer@isc.org\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.0\",\"vectorString\":\"CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":6.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"ADJACENT_NETWORK\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":2.8,\"impactScore\":3.6},{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.0\",\"vectorString\":\"CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":7.5,\"baseSeverity\":\"HIGH\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":3.9,\"impactScore\":3.6}],\"cvssMetricV2\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"2.0\",\"vectorString\":\"AV:N/AC:L/Au:N/C:N/I:N/A:P\",\"baseScore\":5.0,\"accessVector\":\"NETWORK\",\"accessComplexity\":\"LOW\",\"authentication\":\"NONE\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"PARTIAL\"},\"baseSeverity\":\"MEDIUM\",\"exploitabilityScore\":10.0,\"impactScore\":2.9,\"acInsufInfo\":false,\"obtainAllPrivilege\":false,\"obtainUserPrivilege\":false,\"obtainOtherPrivilege\":false,\"userInteractionRequired\":false}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-772\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:a:isc:kea:1.4.0:*:*:*:*:*:*:*\",\"matchCriteriaId\":\"E0A6F1B5-E158-4C10-9C2D-57CEF9B8CF9E\"}]}]}],\"references\":[{\"url\":\"https://kb.isc.org/docs/aa-01626\",\"source\":\"security-officer@isc.org\",\"tags\":[\"Vendor Advisory\"]},{\"url\":\"https://kb.isc.org/docs/aa-01626\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Vendor Advisory\"]}]}}"
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.