-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-16:16.ntp Security Advisory The FreeBSD Project Topic: Multiple vulnerabilities of ntp Category: contrib Module: ntp Announced: 2016-04-29 Credits: Network Time Foundation and various contributors listed below Affects: All supported versions of FreeBSD. Corrected: 2016-04-27 15:24:33 UTC (stable/10, 10.3-STABLE) 2016-04-29 08:02:31 UTC (releng/10.3, 10.3-RELEASE-p1) 2016-04-29 08:02:31 UTC (releng/10.2, 10.2-RELEASE-p15) 2016-04-29 08:02:31 UTC (releng/10.1, 10.1-RELEASE-p32) 2016-04-27 15:25:18 UTC (stable/9, 9.3-STABLE) 2016-04-29 08:02:31 UTC (releng/9.3, 9.3-RELEASE-p40) CVE Name: CVE-2016-1547, CVE-2016-1548, CVE-2016-1549, CVE-2016-1550, CVE-2016-1551, CVE-2016-2516, CVE-2016-2517, CVE-2016-2518, CVE-2016-2519 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The ntpd(8) daemon is an implementation of the Network Time Protocol (NTP) used to synchronize the time of a computer system to a reference time source. II. Problem Description Multiple vulnerabilities have been discovered in the NTP suite: On OSes (FreeBSD not affected) that allows packets claiming to be from 127.0.0.0/8 that arrive over physical network, if ntpd is configured to use a reference clock, an attacker can inject packets over the network that look like they are coming from that reference clock. [CVE-2016-1551, Reported by Matt Street and others of Cisco ASIG] If a system is set up to use a trustedkey, and if one is not using the feature introduced in ntp-4.2.8p6 allowing an optional 4th field in the ntp.keys file to specify which IPs can serve time, a malicious authenticated peer -- i.e. one where the attacker knows the private symmetric key -- can create arbitrarily-many ephemeral associations in order to win the clock selection of ntpd and modify a victim's clock. [CVE-2016-1549, Reported by Matthew Van Gundy of Cisco ASIG] If ntpd was expressly configured to allow for remote configuration (this is not common), a malicious user who knows the controlkey for ntpq or the requestkey for ntpdc (if mode7 is expressly enabled) can create a session with ntpd and if an existing association is unconfigured using the same IP twice on the unconfig directive line, ntpd will abort. [CVE-2016-2516, Reported by Yihan Lian of the Cloud Security Team, Qihoo 360] If ntpd was expressly configured to allow for remote configuration (this is not common), a malicious user who knows the controlkey for ntpq or the requestkey for ntpdc (if mode7 is expressly enabled) can create a session with ntpd and then send a crafted packet to ntpd that will change the value of the trustedkey, controlkey, or requestkey to a value that will prevent any subsequent authentication with ntpd until ntpd is restarted. [CVE-2016-2517, Reported by Yihan Lian of the Cloud Security Team, Qihoo 360] Using a crafted packet to create a peer association with hmode > 7 causes the MATCH_ASSOC() lookup to make an out-of-bounds reference. [CVE-2016-2518, Reported by Yihan Lian of the Cloud Security Team, Qihoo 360] ntpq and ntpdc can be used to store and retrieve information in ntpd. It is possible to store a data value that is larger than the size of the buffer that the ctl_getitem() function of ntpd uses to report the return value. If the length of the requested data value returned by ctl_getitem() is too large, the value NULL is returned instead. There are 2 cases where the return value from ctl_getitem() was not directly checked to make sure it's not NULL, but there are subsequent INSIST() checks that make sure the return value is not NULL. There are no data values ordinarily stored in ntpd that would exceed this buffer length. But if one has permission to store values and one stores a value that is "too large", then ntpd will abort if an attempt is made to read that oversized value. [CVE-2016-2519, Reported by Yihan Lian of the Cloud Security Team, Qihoo 360] For ntp-4 versions up to but not including ntp-4.2.8p7, an off-path attacker can cause a preemptable client association to be demobilized by sending a crypto NAK packet to a victim client with a spoofed source address of an existing associated peer. This is true even if authentication is enabled. Furthermore, if the attacker keeps sending crypto NAK packets, for example one every second, the victim never has a chance to reestablish the association and synchronize time with that legitimate server. For ntp-4.2.8 up to ntp-4.2.8p6 there is less risk because more stringent checks are performed on incoming packets, but there are still ways to exploit this vulnerability in versions before ntp-4.2.8p7. [CVE-2016-1547, Reported by Stephen Gray and Matthew Van Gundy of Cisco ASIG] It is possible to change the time of an ntpd client or deny service to an ntpd client by forcing it to change from basic client/server mode to interleaved symmetric mode. An attacker can spoof a packet from a legitimate ntpd server with an origin timestamp that matches the peer->dst timestamp recorded for that server. After making this switch, the client will reject all future legitimate server responses. It is possible to force the victim client to move time after the mode has been changed. ntpq gives no indication that the mode has been switched. [CVE-2016-1548, Reported by Miroslav Lichvar of RedHat and separately by Jonathan Gardner of Cisco ASIG] Packet authentication tests have been performed using memcmp() or possibly bcmp(), and it is potentially possible for a local or perhaps LAN-based attacker to send a packet with an authentication payload and indirectly observe how much of the digest has matched. [CVE-2016-1550, Reported independently by Loganaden Velvindron, and Matthew Van Gundy and Stephen Gray of Cisco ASIG] III. Impact Malicious remote attackers may be able to break time synchornization, or cause the ntpd(8) daemon to crash. IV. Workaround No workaround is available, but systems not running ntpd(8) are not affected. Network administrators are advised to implement BCP-38, which helps to reduce risk associated with the attacks. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. The ntpd service has to be restarted after the update. A reboot is recommended but not required. 2) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install The ntpd service has to be restarted after the update. A reboot is recommended but not required. 3) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch https://security.FreeBSD.org/patches/SA-16:16/ntp.patch # fetch https://security.FreeBSD.org/patches/SA-16:16/ntp.patch.asc # gpg --verify ntp.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile the operating system using buildworld and installworld as described in . Restart the applicable daemons, or reboot the system. VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/9/ r298700 releng/9.3/ r298770 stable/10/ r298699 releng/10.1/ r298770 releng/10.2/ r298770 releng/10.3/ r298770 - ------------------------------------------------------------------------- To see which files were modified by a particular revision, run the following command, replacing NNNNNN with the revision number, on a machine with Subversion installed: # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base Or visit the following URL, replacing NNNNNN with the revision number: VII. References The latest revision of this advisory is available at -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.11 (FreeBSD) iQIcBAEBCgAGBQJXIxXiAAoJEO1n7NZdz2rnAXgP/0OzpMmgCt4H9ldywUWaFmtr ppIrbIXEuruh08TqrBm+PgUKFT0rZptCtX5pvZ/CwPdqfaisbvWkphcMART47q/Y NcysqVGddmQUvrYihirYloj8qiODPu6XNqSG6QS4fw26NP1/dPnUmAREsTukWJjk rAE+YZloikmKHXPXmG0Dr2STlzLrPDpeEp0aEb+MybZLerzyS6OyzTrnDLHttkwb PFdA54KH4kUzCKJu3O4xtXimMjRm8s7tyOSHQhCI3U6bgTB0Q3hU+9FDFsx3K/7+ LsIa3JVefdgcIRnKWqli31Nk3fyndYgjFXpcqdUnK7bA0RpliGPqW90gom6W+Jb7 uRE5BDWHH3z9KAAGtOpziN20aWXeHHuisDpyfLVNyE350qyKuoVR/FPEa6mc2Fc4 CN53AfTQYPnGrwH4BnIVg2AsOmwwrEWx/TvzQ2DZLrKsUCklWXiUOxHz+6jXlz5v RGIYJtJX/B+QN5a3RgAcluMb/A08FzjyAx57mEkYesv4nQn+9i2lLCP/LFHxId49 3rTmk817Mx1SMIS8Xc1bnd94gOBK8kNuduiV0xVKoJIn4IK5puwy/CBtx2jfMfI7 FPN6Krm7cQDy7z1rAZc80gTuIcMqXFNDHVtGVq+AqDQyv6rXL2iM8N+3xgQEe8Ei fKgeiTiC4OSqKYLy/Ut/ =nQp/ -----END PGP SIGNATURE-----