From: Harlan Stenn Date: Mon, 30 Mar 2015 09:11:33 +0000 (+0000) Subject: Start the RC cycle for ntp-4.2.8p2 X-Git-Tag: NTP_4_2_8P2~5^2~1 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=dd09b46a0a2e895da7f0928ed058f51f2cb0a376;p=thirdparty%2Fntp.git Start the RC cycle for ntp-4.2.8p2 bk: 551913450OlkX47Qa27DZsf-cidtwg --- diff --git a/NEWS b/NEWS index 06dcd13fd..22db00f21 100644 --- a/NEWS +++ b/NEWS @@ -1,7 +1,85 @@ --- NTP 4.2.8p2 (Harlan Stenn , 2015/04/xx) -Focus: Bug fixes, enhancements. +Focus: Security and Bug fixes, enhancements. + +Severity: HIGH + +In addition to bug fixes and enhancements, this release fixes the +following high-severity vulnerabilities involving private key +authentication: + +* [Sec 2779] ntpd accepts unauthenticated packets with symmetric key crypto. + + References: Sec 2779 / CVE-2015-1798 / VU#374268 + Affects: All NTP4 releases starting with ntp-4.2.5p99 up to but not + including ntp-4.2.8p2 where the installation uses symmetric keys + to authenticate remote associations. + CVSS: (AV:A/AC:M/Au:N/C:P/I:P/A:P) Base Score: 5.4 + Date Resolved: Stable (4.2.8p2) 07 Apr 2015 + Summary: When ntpd is configured to use a symmetric key to authenticate + a remote NTP server/peer, it checks if the NTP message + authentication code (MAC) in received packets is valid, but not if + there actually is any MAC included. Packets without a MAC are + accepted as if they had a valid MAC. This allows a MITM attacker to + send false packets that are accepted by the client/peer without + having to know the symmetric key. The attacker needs to know the + transmit timestamp of the client to match it in the forged reply + and the false reply needs to reach the client before the genuine + reply from the server. The attacker doesn't necessarily need to be + relaying the packets between the client and the server. + + Authentication using autokey doesn't have this problem as there is + a check that requires the key ID to be larger than NTP_MAXKEY, + which fails for packets without a MAC. + Mitigation: + Upgrade to 4.2.8p2, or later, from the NTP Project Download Page + or the NTP Public Services Project Download Page + Configure ntpd with enough time sources and monitor it properly. + Credit: This issue was discovered by Miroslav Lichvar, of Red Hat. + +* [Sec 2781] Authentication doesn't protect symmetric associations against + DoS attacks. + + References: Sec 2781 / CVE-2015-1799 / VU#374268 + Affects: All NTP releases starting with at least xntp3.3wy up to but + not including ntp-4.2.8p2 where the installation uses symmetric + key authentication. + CVSS: (AV:A/AC:M/Au:N/C:P/I:P/A:P) Base Score: 5.4 + Note: the CVSS base Score for this issue could be 4.3 or lower, and + it could be higher than 5.4. + Date Resolved: Stable (4.2.8p2) 07 Apr 2015 + Summary: An attacker knowing that NTP hosts A and B are peering with + each other (symmetric association) can send a packet to host A + with source address of B which will set the NTP state variables + on A to the values sent by the attacker. Host A will then send + on its next poll to B a packet with originate timestamp that + doesn't match the transmit timestamp of B and the packet will + be dropped. If the attacker does this periodically for both + hosts, they won't be able to synchronize to each other. This is + a known denial-of-service attack, described at + https://www.eecis.udel.edu/~mills/onwire.html . + + According to the document the NTP authentication is supposed to + protect symmetric associations against this attack, but that + doesn't seem to be the case. The state variables are updated even + when authentication fails and the peers are sending packets with + originate timestamps that don't match the transmit timestamps on + the receiving side. + + This seems to be a very old problem, dating back to at least + xntp3.3wy. It's also in the NTPv3 (RFC 1305) and NTPv4 (RFC 5905) + specifications, so other NTP implementations with support for + symmetric associations and authentication may be vulnerable too. + An update to the NTP RFC to correct this error is in-process. + Mitigation: + Upgrade to 4.2.8p2, or later, from the NTP Project Download Page + or the NTP Public Services Project Download Page + Note that for users of autokey, this specific style of MITM attack + is simply a long-known potential problem. + Configure ntpd with appropriate time sources and monitor ntpd. + Alert your staff if problems are detected. + Credit: This issue was discovered by Miroslav Lichvar, of Red Hat. * [Bug 1787] DCF77's formerly "antenna" bit is "call bit" since 2003. * [Bug 1960] setsockopt IPV6_MULTICAST_IF: Invalid argument. @@ -33,6 +111,9 @@ Focus: Bug fixes, enhancements. Reworked mk_utcinfo() to avoid printing of ambiguous leap second dates. Modified mbg_tm_str() which now expexts an additional parameter controlling if the time status shall be printed. +* [Sec 2779] ntpd accepts unauthenticated packets with symmetric key crypto. +* [Sec 2781] Authentication doesn't protect symmetric associations against + DoS attacks. * [Bug 2783] Quiet autoconf warnings about missing AC_LANG_SOURCE. * [Bug 2789] Quiet compiler warnings from libevent. * [Bug 2790] If ntpd sets the Windows MM timer highest resolution