From ${URL} : 1)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. 2)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. @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
*** Bug 545990 has been marked as a duplicate of this bug. ***
Commit message: Version bump http://sources.gentoo.org/net-misc/ntp/ntp-4.2.8_p2.ebuild?rev=1.1
(In reply to SpanKY from comment #2) > Commit message: Version bump > http://sources.gentoo.org/net-misc/ntp/ntp-4.2.8_p2.ebuild?rev=1.1 !!! Couldn't download 'ntp-4.2.8p2-manpages.tar.bz2'. Aborting. * Fetch failed for 'net-misc/ntp-4.2.8_p2', Log file: * '/var/tmp/portage/net-misc/ntp-4.2.8_p2/temp/build.log' >>> Failed to emerge net-misc/ntp-4.2.8_p2
(In reply to cilly from comment #3) uploaded
CVE-2015-1799 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-1799): The symmetric-key feature in the receive function in ntp_proto.c in ntpd in NTP 3.x and 4.x before 4.2.8p2 performs state-variable updates upon receiving certain invalid packets, which makes it easier for man-in-the-middle attackers to cause a denial of service (synchronization loss) by spoofing the source IP address of a peer. CVE-2015-1798 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-1798): The symmetric-key feature in the receive function in ntp_proto.c in ntpd in NTP 4.x before 4.2.8p2 requires a correct MAC only if the MAC field has a nonzero length, which makes it easier for man-in-the-middle attackers to spoof packets by omitting the MAC.
Added to an existing GLSA Request. Maintainer(s), please drop the vulnerable version(s).
Maintainer(s), please drop the vulnerable version(s).
This issue was resolved and addressed in GLSA 201509-01 at https://security.gentoo.org/glsa/201509-01 by GLSA coordinator Kristian Fiskerstrand (K_F).
Re-Opening for Cleanup Maintainer(s), please drop the vulnerable version(s).
Arches and Maintainer(s), Thank you for your work. closing
