From b2ccf8dd31d1457ae9f0ae270054117179220370 Mon Sep 17 00:00:00 2001 From: Lorry Tar Creator Date: Tue, 7 Apr 2015 08:29:34 +0000 Subject: Imported from /home/lorry/working-area/delta_ntp/ntp-4.2.8p2.tar.gz. --- NEWS | 369 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 364 insertions(+), 5 deletions(-) (limited to 'NEWS') diff --git a/NEWS b/NEWS index bbd260e..a425a9a 100644 --- a/NEWS +++ b/NEWS @@ -1,11 +1,368 @@ --- -NTP 4.2.8- +NTP 4.2.8p2 (Harlan Stenn , 2015/04/xx) + +Focus: Security and Bug fixes, enhancements. + +Severity: MEDIUM + +In addition to bug fixes and enhancements, this release fixes the +following medium-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 Fixes and Improvements: + +* [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. +* [Bug 2728] See if C99-style structure initialization works. +* [Bug 2747] Upgrade libevent to 2.1.5-beta. +* [Bug 2749] ntp/lib/NTP/Util.pm needs update for ntpq -w, IPv6, .POOL. . +* [Bug 2751] jitter.h has stale copies of l_fp macros. +* [Bug 2756] ntpd hangs in startup with gcc 3.3.5 on ARM. +* [Bug 2757] Quiet compiler warnings. +* [Bug 2759] Expose nonvolatile/clk_wander_threshold to ntpq. +* [Bug 2763] Allow different thresholds for forward and backward steps. +* [Bug 2766] ntp-keygen output files should not be world-readable. +* [Bug 2767] ntp-keygen -M should symlink to ntp.keys. +* [Bug 2771] nonvolatile value is documented in wrong units. +* [Bug 2773] Early leap announcement from Palisade/Thunderbolt +* [Bug 2774] Unreasonably verbose printout - leap pending/warning +* [Bug 2775] ntp-keygen.c fails to compile under Windows. +* [Bug 2777] Fixed loops and decoding of Meinberg GPS satellite info. + Removed non-ASCII characters from some copyright comments. + Removed trailing whitespace. + Updated definitions for Meinberg clocks from current Meinberg header files. + Now use C99 fixed-width types and avoid non-ASCII characters in comments. + Account for updated definitions pulled from Meinberg header files. + Updated comments on Meinberg GPS receivers which are not only called GPS16x. + Replaced some constant numbers by defines from ntp_calendar.h + Modified creation of parse-specific variables for Meinberg devices + in gps16x_message(). + 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 + pause briefly before measuring system clock precision to yield + correct results. +* Comment from Juergen Perlinger in ntp_calendar.c to make the code clearer. +* Use predefined function types for parse driver functions + used to set up function pointers. + Account for changed prototype of parse_inp_fnc_t functions. + Cast parse conversion results to appropriate types to avoid + compiler warnings. + Let ioctl() for Windows accept a (void *) to avoid compiler warnings + when called with pointers to different types. + +--- +NTP 4.2.8p1 (Harlan Stenn , 2015/02/04) + +Focus: Security and Bug fixes, enhancements. + +Severity: HIGH + +In addition to bug fixes and enhancements, this release fixes the +following high-severity vulnerabilities: + +* vallen is not validated in several places in ntp_crypto.c, leading + to a potential information leak or possibly a crash + + References: Sec 2671 / CVE-2014-9297 / VU#852879 + Affects: All NTP4 releases before 4.2.8p1 that are running autokey. + CVSS: (AV:N/AC:L/Au:N/C:P/I:P/A:P) Base Score: 7.5 + Date Resolved: Stable (4.2.8p1) 04 Feb 2015 + Summary: The vallen packet value is not validated in several code + paths in ntp_crypto.c which can lead to information leakage + or perhaps a crash of the ntpd process. + Mitigation - any of: + Upgrade to 4.2.8p1, or later, from the NTP Project Download Page + or the NTP Public Services Project Download Page. + Disable Autokey Authentication by removing, or commenting out, + all configuration directives beginning with the "crypto" + keyword in your ntp.conf file. + Credit: This vulnerability was discovered by Stephen Roettger of the + Google Security Team, with additional cases found by Sebastian + Krahmer of the SUSE Security Team and Harlan Stenn of Network + Time Foundation. + +* ::1 can be spoofed on some OSes, so ACLs based on IPv6 ::1 addresses + can be bypassed. + + References: Sec 2672 / CVE-2014-9298 / VU#852879 + Affects: All NTP4 releases before 4.2.8p1, under at least some + versions of MacOS and Linux. *BSD has not been seen to be vulnerable. + CVSS: (AV:N/AC:L/Au:N/C:P/I:P/A:C) Base Score: 9 + Date Resolved: Stable (4.2.8p1) 04 Feb 2014 + Summary: While available kernels will prevent 127.0.0.1 addresses + from "appearing" on non-localhost IPv4 interfaces, some kernels + do not offer the same protection for ::1 source addresses on + IPv6 interfaces. Since NTP's access control is based on source + address and localhost addresses generally have no restrictions, + an attacker can send malicious control and configuration packets + by spoofing ::1 addresses from the outside. Note Well: This is + not really a bug in NTP, it's a problem with some OSes. If you + have one of these OSes where ::1 can be spoofed, ALL ::1 -based + ACL restrictions on any application can be bypassed! + Mitigation: + Upgrade to 4.2.8p1, or later, from the NTP Project Download Page + or the NTP Public Services Project Download Page + Install firewall rules to block packets claiming to come from + ::1 from inappropriate network interfaces. + Credit: This vulnerability was discovered by Stephen Roettger of + the Google Security Team. + +Additionally, over 30 bugfixes and improvements were made to the codebase. +See the ChangeLog for more information. + +--- +NTP 4.2.8 (Harlan Stenn , 2014/12/18) + +Focus: Security and Bug fixes, enhancements. + +Severity: HIGH + +In addition to bug fixes and enhancements, this release fixes the +following high-severity vulnerabilities: + +************************** vv NOTE WELL vv ***************************** + +The vulnerabilities listed below can be significantly mitigated by +following the BCP of putting + + restrict default ... noquery + +in the ntp.conf file. With the exception of: + + receive(): missing return on error + References: Sec 2670 / CVE-2014-9296 / VU#852879 + +below (which is a limited-risk vulnerability), none of the recent +vulnerabilities listed below can be exploited if the source IP is +restricted from sending a 'query'-class packet by your ntp.conf file. + +************************** ^^ NOTE WELL ^^ ***************************** + +* Weak default key in config_auth(). + + References: [Sec 2665] / CVE-2014-9293 / VU#852879 + CVSS: (AV:N/AC:L/Au:M/C:P/I:P/A:C) Base Score: 7.3 + Vulnerable Versions: all releases prior to 4.2.7p11 + Date Resolved: 28 Jan 2010 + + Summary: If no 'auth' key is set in the configuration file, ntpd + would generate a random key on the fly. There were two + problems with this: 1) the generated key was 31 bits in size, + and 2) it used the (now weak) ntp_random() function, which was + seeded with a 32-bit value and could only provide 32 bits of + entropy. This was sufficient back in the late 1990s when the + code was written. Not today. + + Mitigation - any of: + - Upgrade to 4.2.7p11 or later. + - Follow BCP and put 'restrict ... noquery' in your ntp.conf file. + + Credit: This vulnerability was noticed in ntp-4.2.6 by Neel Mehta + of the Google Security Team. + +* Non-cryptographic random number generator with weak seed used by + ntp-keygen to generate symmetric keys. + + References: [Sec 2666] / CVE-2014-9294 / VU#852879 + CVSS: (AV:N/AC:L/Au:M/C:P/I:P/A:C) Base Score: 7.3 + Vulnerable Versions: All NTP4 releases before 4.2.7p230 + Date Resolved: Dev (4.2.7p230) 01 Nov 2011 + + Summary: Prior to ntp-4.2.7p230 ntp-keygen used a weak seed to + prepare a random number generator that was of good quality back + in the late 1990s. The random numbers produced was then used to + generate symmetric keys. In ntp-4.2.8 we use a current-technology + cryptographic random number generator, either RAND_bytes from + OpenSSL, or arc4random(). + + Mitigation - any of: + - Upgrade to 4.2.7p230 or later. + - Follow BCP and put 'restrict ... noquery' in your ntp.conf file. + + Credit: This vulnerability was discovered in ntp-4.2.6 by + Stephen Roettger of the Google Security Team. + +* Buffer overflow in crypto_recv() + + References: Sec 2667 / CVE-2014-9295 / VU#852879 + CVSS: (AV:N/AC:L/Au:N/C:P/I:P/A:P) Base Score: 7.5 + Versions: All releases before 4.2.8 + Date Resolved: Stable (4.2.8) 18 Dec 2014 + + Summary: When Autokey Authentication is enabled (i.e. the ntp.conf + file contains a 'crypto pw ...' directive) a remote attacker + can send a carefully crafted packet that can overflow a stack + buffer and potentially allow malicious code to be executed + with the privilege level of the ntpd process. + + Mitigation - any of: + - Upgrade to 4.2.8, or later, or + - Disable Autokey Authentication by removing, or commenting out, + all configuration directives beginning with the crypto keyword + in your ntp.conf file. + + Credit: This vulnerability was discovered by Stephen Roettger of the + Google Security Team. + +* Buffer overflow in ctl_putdata() + + References: Sec 2668 / CVE-2014-9295 / VU#852879 + CVSS: (AV:N/AC:L/Au:N/C:P/I:P/A:P) Base Score: 7.5 + Versions: All NTP4 releases before 4.2.8 + Date Resolved: Stable (4.2.8) 18 Dec 2014 + + Summary: A remote attacker can send a carefully crafted packet that + can overflow a stack buffer and potentially allow malicious + code to be executed with the privilege level of the ntpd process. + + Mitigation - any of: + - Upgrade to 4.2.8, or later. + - Follow BCP and put 'restrict ... noquery' in your ntp.conf file. + + Credit: This vulnerability was discovered by Stephen Roettger of the + Google Security Team. + +* Buffer overflow in configure() + + References: Sec 2669 / CVE-2014-9295 / VU#852879 + CVSS: (AV:N/AC:L/Au:N/C:P/I:P/A:P) Base Score: 7.5 + Versions: All NTP4 releases before 4.2.8 + Date Resolved: Stable (4.2.8) 18 Dec 2014 + + Summary: A remote attacker can send a carefully crafted packet that + can overflow a stack buffer and potentially allow malicious + code to be executed with the privilege level of the ntpd process. + + Mitigation - any of: + - Upgrade to 4.2.8, or later. + - Follow BCP and put 'restrict ... noquery' in your ntp.conf file. + + Credit: This vulnerability was discovered by Stephen Roettger of the + Google Security Team. + +* receive(): missing return on error + + References: Sec 2670 / CVE-2014-9296 / VU#852879 + CVSS: (AV:N/AC:L/Au:N/C:N/I:N/A:P) Base Score: 5.0 + Versions: All NTP4 releases before 4.2.8 + Date Resolved: Stable (4.2.8) 18 Dec 2014 + + Summary: Code in ntp_proto.c:receive() was missing a 'return;' in + the code path where an error was detected, which meant + processing did not stop when a specific rare error occurred. + We haven't found a way for this bug to affect system integrity. + If there is no way to affect system integrity the base CVSS + score for this bug is 0. If there is one avenue through which + system integrity can be partially affected, the base score + becomes a 5. If system integrity can be partially affected + via all three integrity metrics, the CVSS base score become 7.5. + + Mitigation - any of: + - Upgrade to 4.2.8, or later, + - Remove or comment out all configuration directives + beginning with the crypto keyword in your ntp.conf file. + + Credit: This vulnerability was discovered by Stephen Roettger of the + Google Security Team. + +See http://support.ntp.org/security for more information. + +New features / changes in this release: Important Changes * Internal NTP Era counters -The internal counters that track which "era" (range of years) we are in +The internal counters that track the "era" (range of years) we are in rolls over every 136 years'. The current "era" started at the stroke of midnight on 1 Jan 1900, and ends just before the stroke of midnight on 1 Jan 2036. @@ -16,8 +373,6 @@ more. We now compile a timestamp into the ntpd executable and when we get a timestamp we us the "built-on" to tell us what era we are in. This check "looks back" 10 years, and "looks forward" 126 years. -So if you have a system that ... - * ntpdc responses disabled by default Dave Hart writes: @@ -40,7 +395,7 @@ ntpq's text-based, label=value approach involves more code reuse and allows compatible changes without extra work in most cases. Mode 7 has always been defined as vendor/implementation-specific while -mode 6 is described in RFC 1305 and intended to be open to interop +mode 6 is described in RFC 1305 and intended to be open to interoperate with other implementations. There is an early draft of an updated mode 6 description that likely will join the other NTPv4 RFCs eventually. (http://tools.ietf.org/html/draft-odonoghue-ntpv4-control-01) @@ -51,6 +406,10 @@ deprecating ntpdc. If you are in the habit of using ntpdc for certain operations, please try the ntpq equivalent. If there's no equivalent, please open a bug report at http://bugs.ntp.org./ +In addition to the above, over 1100 issues have been resolved between +the 4.2.6 branch and 4.2.8. The ChangeLog file in the distribution +lists these. + --- NTP 4.2.6p5 (Harlan Stenn , 2011/12/24) -- cgit v1.2.1