Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

[R1] NTP Autokey Functionality Multiple Remote DoS

High

Synopsis

NTP contains three flaws that can be leveraged to remote deny service:

CVE-2015-7691 NTP ntp_crypto.c crypto_xmit() Function Extension Fields Evaluation Remote DoS

The NTP ntpd daemon, with Autokey enabled and configured with GQ identity schemes, has a flaw related to the incomplete patch for CVE-2014-9750. The flaw is in the crypto_xmit() function in ntp_crypto.c.


...
case CRYPTO_CERT | CRYPTO_RESP:
vallen = ntohl(ep->vallen); /* Must be  MAXHOSTNAME ||
len - VALUE_LEN 

The len variable was initialized to 8, which is the current length of the outgoing extension, not the incoming extension. With MAXHOSTNAME = 512 and VALUE_LEN = 24, the expression len - VALUE_LEN will never result in 'true' if it gets evaluated.

CVE-2015-7692 NTP ntp_crypto.c Multiple Function Autokey Packet Handling Remote DoS

In ntp_crypto.c, crypto_bob2(), crypto_bob3(), and cert_sign() functions in ntp_crypto.c are missing length checks for vallen. These functions take an extension sent by a remote client via a client mode packet. The extension is processed through the crypto_xmit() function which does not have an "early" check on vallen.

In crypto_bob2() and crypto_bob3():


...
len = ntohl(ep->vallen);
if ((r = BN_bin2bn((u_char *)ep->pkt, len, NULL)) == NULL) {
...
In cert_sign():
...
cptr = (void *)ep->pkt;
if ((req = d2i_X509(NULL, &cptr, ntohl(ep->vallen))) == NULL) {
...

CVE-2015-7701 NTP Autokey Request Saturation Memory Consumption Remote DoS

The ntpd daemon processes symmetric active NTPv4 packets with multiple extensions. This can cause a memory leak as shown below:


int crypto_recv(...)
{
...
// loop to process (multiple) extensions 
while ((has_mac = rbufp->recv_length - authlen) > (int)MAX_MAC_LEN) {
...
case CRYPTO_ASSOC:
/*
If our state machine is running when this
message arrives, the other fellow might have
restarted. However, this could be an
intruder, so just clamp the poll interval and
find out for ourselves. Otherwise, pass the
extension field to the transmit side.
*/
if (peer->crypto & CRYPTO_FLAG_CERT) { rval = XEVNT_ERR; break; }
if (peer->cmmd)
Unknown macro: {	if (peer->assoc != associd) { rval = XEVNT_ERR; break; }	}
fp = emalloc(len);
memcpy(fp, ep, len);
fp->associd = htonl(peer->associd);
peer->cmmd = fp;
...
}

When processing an extension with an ASSOC Autokey message, ntpd allocates and copies memory for the incoming extension and assigns it to peer->cmmd. However, when multiple ASSOC messages are present in a symmetric active NTPv4 packet, memory pointed by peer->cmmd was not freed prior to the peer->cmmd = fp assignment. This causes a memory leak, which could lead to a denial of service via a series of crafted packets.

Solution

Upgrade to 4.2.8p4 or later, as it resolves these issues.

Disclosure Timeline

2015-06-11 - Issue #1 / #2 discovered
2015-08-11 - Vendor Informed of Issue #1 / #2
2015-08-12 - Vendor confirms receipt of email
2015-08-20 - Vendor asks Tenable to create account on bug tracker for collaboration
2015-08-20 - Tenable created account on bugs.ntp.org
2015-08-20 - CVE requested
2015-08-20 - Bug Tracker ID #2899 created by NTP team (Issue #1 / #2)
2015-08-21 - Preliminary patch created by NTP team
2015-08-26 - Vendor informed of Issue #3
2015-08-26 - Vendor follows-up with MITRE re: CVE assignment
2015-09-28 - Bug Tracker ID #2909 created by NTP team (Issue #3)
2015-09-08 - Ping CVE re: assignment
2015-09-29 - Vendor follows-up with MITRE re: CVE assignment
2015-10-04 - CVE provides assignments
2015-10-06 - Vendor shares preliminary advisory for review, Tenable confirms accurate
2015-10-21 - NTP releases fixed version

All information within TRA advisories is provided “as is”, without warranty of any kind, including the implied warranties of merchantability and fitness for a particular purpose, and with no guarantee of completeness, accuracy, or timeliness. Individuals and organizations are responsible for assessing the impact of any actual or potential security vulnerability.

Tenable takes product security very seriously. If you believe you have found a vulnerability in one of our products, we ask that you please work with us to quickly resolve it in order to protect customers. Tenable believes in responding quickly to such reports, maintaining communication with researchers, and providing a solution in short order.

For more details on submitting vulnerability information, please see our Vulnerability Reporting Guidelines page.

If you have questions or corrections about this advisory, please email [email protected]