From: Harlan Stenn Date: Fri, 19 Dec 2014 08:05:17 +0000 (+0000) Subject: NEWS file for 4.2.8 X-Git-Tag: NTP_4_2_8~4^2 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=87bf4e1ce5097c4e0a6508404e724de2f75a901c;p=thirdparty%2Fntp.git NEWS file for 4.2.8 bk: 5493dc3dofY6drKJde9W-5O1M3s4eg --- diff --git a/NEWS b/NEWS index bbd260e2c..efd488f30 100644 --- a/NEWS +++ b/NEWS @@ -1,11 +1,140 @@ --- -NTP 4.2.8- +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: + +* 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: Upgrade to 4.2.7p11 or later. + + 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: Upgrade to 4.2.7p230 or later. + + 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: 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: Upgrade to 4.2.8, or later. + + 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: Upgrade to 4.2.8, or later. + + 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: + Upgrade to 4.2.8, or later, + or 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 +145,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 +167,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 +178,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)