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 64k */
if (vallen == 0 || vallen > MAXHOSTNAME ||
len - VALUE_LEN vallen)
{ rval = XEVNT_LEN; break; }
...
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 vallen 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.