Start the RC cycle for ntp-4.2.8p2

bk: 551913450OlkX47Qa27DZsf-cidtwg

diff --git a/NEWS b/NEWS
index 06dcd13fd98e0dbddb1ba2303f64e952b714d913..22db00f2148ce749398960ea52637d0a155d2533 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -1,7 +1,85 @@
 ---
 NTP 4.2.8p2 (Harlan Stenn <stenn@ntp.org>, 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