Merge bk://bk.ntp.org/ntp-stable

into  psp-fb1.ntp.org:/a/etc/amd.stage/thump2-g3/export/ntp/home/stenn/ntp-stable-2779-2781

bk: 551e089cW1KvigwRN4qKqBzJLtgipw

diff --cc ChangeLog
Simple merge

diff --cc NEWS
index 5aa21759c8e8a24785e1b0e05ac404ceb784ae1f,22db00f2148ce749398960ea52637d0a155d2533..9ce70d3772612ca9b274b60e5e1333a4b90a9842
--- 1/NEWS
--- 2/NEWS
+++ b/NEWS
@@@ -1,17 -1,86 +1,95 @@@
  ---
  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. 
  
 +* New script: update-leap
 +The update-leap script will verify and if necessary, update the
 +leap-second definition file.
 +It requires the following commands in order to work:
 +
 +      wget logger tr sed shasum
 +
 +Some may choose to run this from cron.  It needs more portability testing.
 +
  * [Bug 1787] DCF77's formerly "antenna" bit is "call bit" since 2003.
  * [Bug 1960] setsockopt IPV6_MULTICAST_IF: Invalid argument.
  * [Bug 2346] "graceful termination" signals do not do peer cleanup.