svn commit: r48746 - in head/share: security/advisories security/patches/SA-16:16 xml
Xin LI
delphij at FreeBSD.org
Fri Apr 29 08:09:31 UTC 2016
Author: delphij
Date: Fri Apr 29 08:09:30 2016
New Revision: 48746
URL: https://svnweb.freebsd.org/changeset/doc/48746
Log:
Add SA-16:16.ntp
Added:
head/share/security/advisories/FreeBSD-SA-16:16.ntp.asc (contents, props changed)
head/share/security/patches/SA-16:16/
head/share/security/patches/SA-16:16/ntp.patch (contents, props changed)
head/share/security/patches/SA-16:16/ntp.patch.asc (contents, props changed)
Modified:
head/share/xml/advisories.xml
Added: head/share/security/advisories/FreeBSD-SA-16:16.ntp.asc
==============================================================================
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/share/security/advisories/FreeBSD-SA-16:16.ntp.asc Fri Apr 29 08:09:30 2016 (r48746)
@@ -0,0 +1,234 @@
+-----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 <URL:https://security.FreeBSD.org/>.
+
+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 <URL:https://www.FreeBSD.org/handbook/makeworld.html>.
+
+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:
+
+<URL:https://svnweb.freebsd.org/base?view=revision&revision=NNNNNN>
+
+VII. References
+
+<URL:http://support.ntp.org/bin/view/Main/SecurityNotice#April_2016_NTP_4_2_8p7_Security>
+
+<URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1547>
+
+<URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1548>
+
+<URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1549>
+
+<URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1550>
+
+<URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-1551>
+
+<URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2516>
+
+<URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2517>
+
+<URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2518>
+
+<URL:https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2519>
+
+The latest revision of this advisory is available at
+<URL:https://security.FreeBSD.org/advisories/FreeBSD-SA-16:16.ntp.asc>
+-----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-----
Added: head/share/security/patches/SA-16:16/ntp.patch
==============================================================================
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/share/security/patches/SA-16:16/ntp.patch Fri Apr 29 08:09:30 2016 (r48746)
@@ -0,0 +1,11115 @@
+--- contrib/ntp/html/authentic.html.orig
++++ contrib/ntp/html/authentic.html
+@@ -20,7 +20,7 @@
+ <img src="pic/alice44.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
+ <p>Our resident cryptographer; now you see him, now you don't.</p>
+ <p>Last update:
+- <!-- #BeginDate format:En2m -->1-Dec-2012 04:44<!-- #EndDate -->
++ <!-- #BeginDate format:En2m -->5-Feb-2016 09:13<!-- #EndDate -->
+ UTC</p>
+ <br clear="left">
+ <h4>Related Links</h4>
+@@ -35,28 +35,28 @@
+ </ul>
+ <hr>
+ <h4 id="auth">Introduction</h4>
+-<p>This page describes the various cryptographic authentication provisions in NTPv4. Authentication support allows the NTP client to verify that servers are in fact known and trusted and not intruders intending accidentally or intentionally to masquerade as a legitimate server. A detailed discussion of the NTP multi-layer security model and vulnerability analysis is in the white paper <a href="http://www.eecis.udel.edu/~mills/security.html">NTP Security Analysis</a>.</p>
+-<p> The NTPv3 specification (RFC-1305) defined an authentication scheme properly described as <em>symmetric key cryptography</em>. It used the Data Encryption Standard (DES) algorithm operating in cipher-block chaining (CBC) mode. Subsequently, this algorithm was replaced by the RSA Message Digest 5 (MD5) algorithm commonly called keyed-MD5. Either algorithm computes a message digest or one-way hash which can be used to verify the client has the same message digest as the server. The MD5 message digest algorithm is included in the distribution, so without further cryptographic support, the distribution can be freely exported.</p>
+-<p>If the OpenSSL cryptographic library is installed prior to building the distribution, all message digest algorithms included in the library may be used, including SHA and SHA1. However, if conformance to FIPS 140-2 is required, only a limited subset of these algorithms can be used. This library is available from <a href="http://www.openssl.org">http://www.openssl.org</a> and can be installed using the procedures outlined in the <a href="build.html">Building and Installing the Distribution</a> page. Once installed, the configure and build process automatically detects the library and links the library routines
++<p>This page describes the various cryptographic authentication provisions in NTPv4. Authentication support allows the NTP client to verify that servers are in fact known and trusted and not intruders intending accidentally or intentionally to masquerade as a legitimate server. A detailed discussion of the NTP multi-layer security model and vulnerability analysis is in the white paper <a href="http://www.eecis.udel.edu/~mills/security.html">NTP Security Analysis</a>.</p>
++<p> The NTPv3 specification (RFC-1305) defined an authentication scheme properly described as <em>symmetric key cryptography</em>. It used the Data Encryption Standard (DES) algorithm operating in cipher-block chaining (CBC) mode. Subsequently, this algorithm was replaced by the RSA Message Digest 5 (MD5) algorithm commonly called keyed-MD5. Either algorithm computes a message digest or one-way hash which can be used to verify the client has the same message digest as the server. The MD5 message digest algorithm is included in the distribution, so without further cryptographic support, the distribution can be freely exported.</p>
++<p>If the OpenSSL cryptographic library is installed prior to building the distribution, all message digest algorithms included in the library may be used, including SHA and SHA1. However, if conformance to FIPS 140-2 is required, only a limited subset of these algorithms can be used. This library is available from <a href="http://www.openssl.org">http://www.openssl.org</a> and can be installed using the procedures outlined in the <a href="build.html">Building and Installing the Distribution</a> page. Once installed, the configure and build process automatically detects the library and links the library routines
+ required.</p>
+-<p>In addition to the symmetric key algorithms, this distribution includes support for the Autokey public key algorithms and protocol specified in RFC-5906 "Network Time Protocol Version 4: Autokey Specification". This support is available only if the OpenSSL library has been installed and the <tt>--enable-autokey</tt> option is used when the distribution is built.</p>
+-<p> Public key cryptography is generally considered more secure than symmetric key cryptography, since the security is based on private and public values which are generated by each participant and where the private value is never revealed. Autokey uses X.509 public certificates, which can be produced by commercial services, the OpenSSL application program, or the <a href="keygen.html"><tt>ntp-keygen</tt></a> utility program in the NTP software distribution.</p>
+-<p>Note that according to US law, NTP binaries including OpenSSL library components, including the OpenSSL library itself, cannot be exported outside the US without license from the US Department of Commerce. Builders outside the US are advised to obtain the OpenSSL library directly from OpenSSL, which is outside the US, and build outside the US.</p>
+-<p>Authentication is configured separately for each association using the <tt>key</tt> or <tt>autokey</tt> option of the <tt>server</tt> configuration command, as described in the <a href="confopt.html">Server Options</a> page. The <a href="keygen.html">ntp-keygen</a> page describes the files required for the various authentication schemes. Further details are in the briefings, papers and reports at the NTP project page linked from <a href="http://www.ntp.org">www.ntp.org</a>.</p>
+-<p>By default, the client sends non-authenticated packets and the server responds with non-authenticated packets. If the client sends authenticated packets, the server responds with authenticated packets if correct, or a crypto-NAK packet if not.. In the case of unsolicited packets which might consume significant resources, such as broadcast or symmetric mode packets, , authentication is required, unless overridden by a <tt>disable auth</tt> command. In the current climate of targeted broadcast or "letterbomb" attacks, defeating this requirement would be decidedly dangerous. In any case, the <tt>notrust </tt>flag, described on the <a href="authopt.html">Access Control Options</a> page, can be used to disable access to all but correctly authenticated clients..</p>
++<p>In addition to the symmetric key algorithms, this distribution includes support for the Autokey public key algorithms and protocol specified in RFC-5906 "Network Time Protocol Version 4: Autokey Specification". This support is available only if the OpenSSL library has been installed and the <tt>--enable-autokey</tt> option is used when the distribution is built.</p>
++<p> Public key cryptography is generally considered more secure than symmetric key cryptography, since the security is based on private and public values which are generated by each participant and where the private value is never revealed. Autokey uses X.509 public certificates, which can be produced by commercial services, the OpenSSL application program, or the <a href="keygen.html"><tt>ntp-keygen</tt></a> utility program in the NTP software distribution.</p>
++<p>Note that according to US law, NTP binaries including OpenSSL library components, including the OpenSSL library itself, cannot be exported outside the US without license from the US Department of Commerce. Builders outside the US are advised to obtain the OpenSSL library directly from OpenSSL, which is outside the US, and build outside the US.</p>
++<p>Authentication is configured separately for each association using the <tt>key</tt> or <tt>autokey</tt> option of the <tt>server</tt> configuration command, as described in the <a href="confopt.html">Server Options</a> page. The <a href="keygen.html">ntp-keygen</a> page describes the files required for the various authentication schemes. Further details are in the briefings, papers and reports at the NTP project page linked from <a href="http://www.ntp.org">www.ntp.org</a>.</p>
++<p>By default, the client sends non-authenticated packets and the server responds with non-authenticated packets. If the client sends authenticated packets, the server responds with authenticated packets if correct, or a crypto-NAK packet if not. In the case of unsolicited packets which might consume significant resources, such as broadcast or symmetric mode packets, authentication is required, unless overridden by a <tt>disable auth</tt> command. In the current climate of targeted broadcast or "letterbomb" attacks, defeating this requirement would be decidedly dangerous. In any case, the <tt>notrust </tt>flag, described on the <a href="authopt.html">Access Control Options</a> page, can be used to disable access to all but correctly authenticated clients.</p>
+ <h4 id="symm">Symmetric Key Cryptography</h4>
+-<p>The original NTPv3 specification (RFC-1305), as well as the current NTPv4 specification (RFC-5905), allows any one of possibly 65,534 message digest keys (excluding zero), each distinguished by a 32-bit key ID, to authenticate an association. The servers and clients involved must agree on the key ID, key type and key to authenticate NTP packets.</p>
+-<p>The message digest is a cryptographic hash computed by an algorithm such as MD5 or SHA. When authentication is specified, a message authentication code (MAC) is appended to the NTP packet header. The MAC consists of a 32-bit key identifier (key ID) followed by a 128- or 160-bit message digest. The algorithm computes the digest as the hash of a 128- or 160- bit message digest key concatenated with the NTP packet header fields with the exception of the MAC. On transmit, the message digest is computed and inserted in the MAC. On receive, the message digest is computed and compared with the MAC. The packet is accepted only if the two MACs are identical. If a discrepancy is found by the client, the client ignores the packet, but raises an alarm. If this happens at the server, the server returns a special message called a <em>crypto-NAK</em>. Since the crypto-NAK is protected by the loopback test, an intruder cannot disrupt the protocol by sending a bogus crypto-NAK.</p>
+-<p>Keys and related information are specified in a keys file, which must be distributed and stored using secure means beyond the scope of the NTP protocol itself. Besides the keys used for ordinary NTP associations, additional keys can be used as passwords for the <tt><a href="ntpq.html">ntpq</a></tt> and <tt><a href="ntpdc.html">ntpdc</a></tt> utility programs. Ordinarily, the <tt>ntp.keys</tt> file is generated by the <tt><a href="keygen.html">ntp-keygen</a></tt> program, but it can be constructed and edited using an ordinary text editor.</p>
+-<p> Each line of the keys file consists of three fields: a key ID in the range 1 to 65,534, inclusive, a key type, and a message digest key consisting of a printable ASCII string less than 40 characters, or a 40-character hex digit string. If the OpenSSL library is installed, the key type can be any message digest algorithm supported by the library. If the OpenSSL library is not installed, the only permitted key type is MD5.</p>
++<p>The original NTPv3 specification (RFC-1305), as well as the current NTPv4 specification (RFC-5905), allows any one of possibly 65,534 message digest keys (excluding zero), each distinguished by a 32-bit key ID, to authenticate an association. The servers and clients involved must agree on the key ID, key type and key to authenticate NTP packets.</p>
++<p>The message digest is a cryptographic hash computed by an algorithm such as MD5 or SHA. When authentication is specified, a message authentication code (MAC) is appended to the NTP packet header. The MAC consists of a 32-bit key identifier (key ID) followed by a 128- or 160-bit message digest. The algorithm computes the digest as the hash of a 128- or 160- bit message digest key concatenated with the NTP packet header fields with the exception of the MAC. On transmit, the message digest is computed and inserted in the MAC. On receive, the message digest is computed and compared with the MAC. The packet is accepted only if the two MACs are identical. If a discrepancy is found by the client, the client ignores the packet, but raises an alarm. If this happens at the server, the server returns a special message called a <em>crypto-NAK</em>. Since the crypto-NAK is protected by the loopback test, an intruder cannot disrupt the protocol by sending a bogus crypto-NAK.</p>
++<p>Keys and related information are specified in a keys file, which must be distributed and stored using secure means beyond the scope of the NTP protocol itself. Besides the keys used for ordinary NTP associations, additional keys can be used as passwords for the <tt><a href="ntpq.html">ntpq</a></tt> and <tt><a href="ntpdc.html">ntpdc</a></tt> utility programs. Ordinarily, the <tt>ntp.keys</tt> file is generated by the <tt><a href="keygen.html">ntp-keygen</a></tt> program, but it can be constructed and edited using an ordinary text editor.</p>
++<p> Each line of the keys file consists of three or four fields: a key ID in the range 1 to 65,534, inclusive, a key type, a message digest key consisting of a printable ASCII string less than 40 characters or a 40-character hex digit string, and an optional comma-separated list of IPs that are allowed to serve time. If the OpenSSL library is installed, the key type can be any message digest algorithm supported by the library. If the OpenSSL library is not installed, the only permitted key type is MD5.</p>
+ <div align="center">
+ <p><img src="pic/sx5.gif" alt="gif"></p>
+ <p>Figure 1. Typical Symmetric Key File</p>
+ </div>
+-<p>Figure 1 shows a typical keys file used by the reference implementation when the OpenSSL library is installed. In this figure, for key IDs in he range 1-10, the key is interpreted as a printable ASCII string. For key IDs in the range 11-20, the key is a 40-character hex digit string. The key is truncated or zero-filled internally to either 128 or 160 bits, depending on the key type. The line can be edited later or new lines can be added to change any field. The key can be change to a password, such as <tt>2late4Me</tt> for key ID 10. Note that two or more keys files can be combined in any order as long as the key IDs are distinct.</p>
+-<p>When <tt>ntpd</tt> is started, it reads the keys file specified by the <tt>keys</tt> command and installs the keys in the key cache. However, individual keys must be activated with the <tt>trustedkey</tt> configuration command before use. This allows, for instance, the installation of possibly several batches of keys and then activating a key remotely using <tt>ntpq</tt> or <tt>ntpdc</tt>. The <tt>requestkey</tt> command selects the key ID used as the password for the <tt>ntpdc</tt> utility, while the <tt>controlkey</tt> command selects the key ID used as the password for the <tt>ntpq</tt> utility.</p>
++<p>Figure 1 shows a typical keys file used by the reference implementation when the OpenSSL library is installed. In this figure, for key IDs in he range 1-10, the key is interpreted as a printable ASCII string. For key IDs in the range 11-20, the key is a 40-character hex digit string. The key is truncated or zero-filled internally to either 128 or 160 bits, depending on the key type. The line can be edited later or new lines can be added to change any field. The key can be change to a password, such as <tt>2late4Me</tt> for key ID 10. Note that two or more keys files can be combined in any order as long as the key IDs are distinct.</p>
++<p>When <tt>ntpd</tt> is started, it reads the keys file specified by the <tt>keys</tt> command and installs the keys in the key cache. However, individual keys must be activated with the <tt>trustedkey</tt> configuration command before use. This allows, for instance, the installation of possibly several batches of keys and then activating a key remotely using <tt>ntpq</tt> or <tt>ntpdc</tt>. The <tt>requestkey</tt> command selects the key ID used as the password for the <tt>ntpdc</tt> utility, while the <tt>controlkey</tt> command selects the key ID used as the password for the <tt>ntpq</tt> utility.</p>
+ <h4 id="windows">Microsoft Windows Authentication</h4>
+-<p>In addition to the above means, <tt>ntpd</tt> now supports Microsoft Windows MS-SNTP authentication using Active Directory services. This support was contributed by the Samba Team and is still in development. It is enabled using the <tt>mssntp</tt> flag of the <tt>restrict</tt> command described on the <a href="accopt.html#restrict">Access Control Options</a> page. <span class="style1">Note: Potential users should be aware that these services involve a TCP connection to another process that could potentially block, denying services to other users. Therefore, this flag should be used only for a dedicated server with no clients other than MS-SNTP.</span></p>
++<p>In addition to the above means, <tt>ntpd</tt> now supports Microsoft Windows MS-SNTP authentication using Active Directory services. This support was contributed by the Samba Team and is still in development. It is enabled using the <tt>mssntp</tt> flag of the <tt>restrict</tt> command described on the <a href="accopt.html#restrict">Access Control Options</a> page. <span class="style1">Note: Potential users should be aware that these services involve a TCP connection to another process that could potentially block, denying services to other users. Therefore, this flag should be used only for a dedicated server with no clients other than MS-SNTP.</span></p>
+ <h4 id="pub">Public Key Cryptography</h4>
+ <p>See the <a href="autokey.html">Autokey Public-Key Authentication</a> page.</p>
+ <hr>
+--- contrib/ntp/html/monopt.html.orig
++++ contrib/ntp/html/monopt.html
+@@ -11,7 +11,7 @@
+ <img src="pic/pogo8.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html"></a> from <i>Pogo</i>, Walt Kelly</a>
+ <p>Pig was hired to watch the logs.</p>
+ <p>Last update:
+- <!-- #BeginDate format:En2m -->31-Jan-2014 06:54<!-- #EndDate -->
++ <!-- #BeginDate format:En2m -->14-Feb-2016 09:38<!-- #EndDate -->
+ UTC</p>
+ <br clear="left">
+ <h4>Related Links</h4>
+@@ -295,7 +295,7 @@
+ <dd>The status field is encoded in hex format as described in Appendix B of
+ the NTP specification RFC 1305.</dd>
+ <dt><tt>protostats</tt></dt>
+- <dd>Record significant peer, system and [rptpcp; events. Each significant event
++ <dd>Record significant peer, system and protocol events. Each significant event
+ appends one line to the <tt>protostats</tt> file set:</dd>
+ <dd><tt>49213 525.624 128.4.1.1 963a 8a <i>message</i></tt></dd>
+ <dd>
+--- contrib/ntp/html/xleave.html.orig
++++ contrib/ntp/html/xleave.html
+@@ -11,17 +11,17 @@
+ <img src="pic/pogo4.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
+ <p>You need a little magic.</p>
+ <p>Last update:
+- <!-- #BeginDate format:En2m -->10-Mar-2014 05:25<!-- #EndDate -->
++ <!-- #BeginDate format:En2m -->6-Feb-2016 07:17<!-- #EndDate -->
+ UTC</p>
+ <br clear="left">
+ <hr>
+-<p>In the protocol described in the NTP specification and reference implementation up to now, the transmit timestamp, which is captured before the message digest is computed and the packet queued for output, is properly called as a <em>softstamp</em> The receive timestamp, which is captured after the input driver interrupt routine and before the packet is queued for input, is properly called a <em>drivestamp</em>. For enhanced accuracy it is desirable to capture the transmit timestamp as close to the wire as possible; for example, after the output driver interrupt routine.</p>
+-<p> In other words, we would like to replace the transmit softstamp with a drivestamp, but the problem is the transmit drivestamp is available only after the packet has been sent. A solution for this problem is the two-step or interleaved protocol described on this page and included in the the current reference implementation. In interleaved modes the transmit drivestamp for one packet is actually carried in the immediately following packet. The trick, however, is to implement the interleaved protocol without changing the NTP packet header format, without compromising backwards compatibility and without compromising the error recovery properties.</p>
+-<p> The reference implementation captures a softstamp before the message digest routine and a drivestamp after the output interrupt routine. In this design the latter timestamp can be considered most accurate, as it avoids the various queuing and transmission latencies. The difference between the two timestamps, which is called the interleaved or output delay, varies from 16 μs for a dual-core Pentium running FreeBSD 6.1 to 1100 μs for a Sun Blade 1500 running Solaris 10.</p>
++<p>In the protocol described in the NTP specification and reference implementation up to now, the transmit timestamp, which is captured before the message digest is computed and the packet queued for output, is properly called as a <em>softstamp</em>. The receive timestamp, which is captured after the input driver interrupt routine and before the packet is queued for input, is properly called a <em>drivestamp</em>. For enhanced accuracy it is desirable to capture the transmit timestamp as close to the wire as possible; for example, after the output driver interrupt routine.</p>
++<p> In other words, we would like to replace the transmit softstamp with a drivestamp, but the problem is the transmit drivestamp is available only after the packet has been sent. A solution for this problem is the two-step or interleaved protocol described on this page and included in the the current reference implementation. In interleaved modes the transmit drivestamp for one packet is actually carried in the immediately following packet. The trick, however, is to implement the interleaved protocol without changing the NTP packet header format, without compromising backwards compatibility and without compromising the error recovery properties.</p>
++<p> The reference implementation captures a softstamp before the message digest routine and a drivestamp after the output interrupt routine. In this design the latter timestamp can be considered most accurate, as it avoids the various queuing and transmission latencies. The difference between the two timestamps, which is called the interleaved or output delay, varies from 16 μs (microseconds) for a dual-core Pentium running FreeBSD 6.1 to 1100 μs (microseconds) for a Sun Blade 1500 running Solaris 10.</p>
+ <p>Interleaved mode can be used only in NTP symmetric and broadcast modes.
+ It is activated by the <tt>xleave</tt> option with the <tt>peer</tt> or <tt>broadcast</tt> configuration
+-commands. A broadcast server configured for interleaved mode is transparent to ordinary broadcast clients, so both ordinary and interleaved broadcast clients can use the same packets. An interleaved symmetric active peer automatically switches to ordinary symmetric mode if the other peer is not capable of operation in interleaved mode. </p>
+-<p>As demonstrated in the white paper <a href="http://www.eecis.udel.edu/~mills/onwire.html">Analysis and Simulation of the NTP On-Wire Protocols</a>, the interleaved modes have the same resistance to lost packets, duplicate packets, packets crossed in flight and protocol restarts as the ordinary modes. An application of the interleaved symmetric mode in space missions is presented in the white paper <a href="http://www.eecis.udel.edu/~mills/proximity.html">Time Synchronization for Space Data Links</a>.</p>
++commands. A broadcast server configured for interleaved mode is transparent to ordinary broadcast clients, so both ordinary and interleaved broadcast clients can use the same packets. An interleaved symmetric active peer automatically switches to ordinary symmetric mode if the other peer is not capable of operation in interleaved mode.</p>
++<p>As demonstrated in the white paper <a href="http://www.eecis.udel.edu/~mills/onwire.html">Analysis and Simulation of the NTP On-Wire Protocols</a>, the interleaved modes have the same resistance to lost packets, duplicate packets, packets crossed in flight and protocol restarts as the ordinary modes. An application of the interleaved symmetric mode in space missions is presented in the white paper <a href="http://www.eecis.udel.edu/~mills/proximity.html">Time Synchronization for Space Data Links</a>.</p>
+ <hr>
+ <div align="center"> <img src="pic/pogo1a.gif" alt="gif"> </div>
+ <br>
+--- contrib/ntp/include/ntp.h.orig
++++ contrib/ntp/include/ntp.h
+@@ -175,6 +175,7 @@
+ struct interface {
+ endpt * elink; /* endpt list link */
+ endpt * mclink; /* per-AF_* multicast list */
++ void * ioreg_ctx; /* IO registration context */
+ SOCKET fd; /* socket descriptor */
+ SOCKET bfd; /* for receiving broadcasts */
+ u_int32 ifnum; /* endpt instance count */
+@@ -242,6 +243,13 @@
+ #define PEER_TEST_MASK (TEST10 | TEST11 | TEST12 | TEST13)
+
+ /*
++ * Unused flags
++ */
++#define TEST14 0x2000
++#define TEST15 0x4000
++#define TEST16 0x8000
++
++/*
+ * The peer structure. Holds state information relating to the guys
+ * we are peering with. Most of this stuff is from section 3.2 of the
+ * spec.
+@@ -391,6 +399,7 @@
+ u_long received; /* packets received */
+ u_long processed; /* packets processed */
+ u_long badauth; /* bad authentication (TEST5) */
++ u_long badNAK; /* invalid crypto-NAK */
+ u_long bogusorg; /* bogus origin (TEST2, TEST3) */
+ u_long oldpkt; /* old duplicate (TEST1) */
+ u_long seldisptoolarge; /* bad header (TEST6, TEST7) */
+@@ -545,6 +554,7 @@
+ l_fp rec; /* receive time stamp */
+ l_fp xmt; /* transmit time stamp */
+
++#define MIN_V4_PKT_LEN (12 * sizeof(u_int32)) /* min header length */
+ #define LEN_PKT_NOMAC (12 * sizeof(u_int32)) /* min header length */
+ #define MIN_MAC_LEN (1 * sizeof(u_int32)) /* crypto_NAK */
+ #define MAX_MD5_LEN (5 * sizeof(u_int32)) /* MD5 */
+--- contrib/ntp/include/ntp_keyacc.h.orig
++++ contrib/ntp/include/ntp_keyacc.h
+@@ -10,4 +10,10 @@
+ sockaddr_u addr;
+ };
+
++extern KeyAccT* keyacc_new_push(KeyAccT *head, const sockaddr_u *addr);
++extern KeyAccT* keyacc_pop_free(KeyAccT *head);
++extern KeyAccT* keyacc_all_free(KeyAccT *head);
++extern int keyacc_contains(const KeyAccT *head, const sockaddr_u *addr,
++ int res_on_empty_list);
++
+ #endif /* NTP_KEYACC_H */
+--- contrib/ntp/include/ntp_refclock.h.orig
++++ contrib/ntp/include/ntp_refclock.h
+@@ -105,7 +105,8 @@
+ int active; /* nonzero when in use */
+
+ #ifdef HAVE_IO_COMPLETION_PORT
+- void * device_context; /* device-related data for i/o subsystem */
++ void * ioreg_ctx; /* IO registration context */
++ void * device_ctx; /* device-related data for i/o subsystem */
+ #endif
+ };
+
+--- contrib/ntp/include/ntp_stdlib.h.orig
++++ contrib/ntp/include/ntp_stdlib.h
+@@ -200,7 +200,7 @@
+ extern keyid_t cache_keyid; /* key identifier */
+ extern int cache_type; /* key type */
+ extern u_char * cache_secret; /* secret */
+-extern u_short cache_secretsize; /* secret octets */
++extern size_t cache_secretsize; /* secret octets */
+ extern u_short cache_flags; /* KEY_ bit flags */
+
+ /* getopt.c */
+--- contrib/ntp/include/ntp_types.h.orig
++++ contrib/ntp/include/ntp_types.h
+@@ -35,6 +35,13 @@
+ # define FALSE 0
+ #endif
+
++#ifdef HAVE_STDBOOL_H
++# include <stdbool.h>
++#else
++typedef int bool; /* Can't use enum TRUE/FALSE because of above */
++#endif
++
++
+ /*
+ * This is another naming conflict.
+ * On NetBSD for MAC the macro "mac" is defined as 1
+--- contrib/ntp/include/ntp_worker.h.orig
++++ contrib/ntp/include/ntp_worker.h
+@@ -119,11 +119,11 @@
+ int resp_write_pipe; /* child */
+ int ispipe;
+ void * resp_read_ctx; /* child */
+- volatile u_int resp_ready_seen; /* signal/scan */
+- volatile u_int resp_ready_done; /* consumer/mainloop */
+ #else
+ sem_ref responses_pending; /* signalling */
+ #endif
++ volatile u_int resp_ready_seen; /* signal/scan */
++ volatile u_int resp_ready_done; /* consumer/mainloop */
+ sema_type sem_table[4];
+ thread_type thr_table[1];
+ } blocking_child;
+@@ -171,6 +171,8 @@
+ extern void kill_asyncio (int);
+ #endif
+
++extern void worker_global_lock(int inOrOut);
++
+ # ifdef WORK_PIPE
+ typedef void (*addremove_io_fd_func)(int, int, int);
+ extern addremove_io_fd_func addremove_io_fd;
+--- contrib/ntp/include/recvbuff.h.orig
++++ contrib/ntp/include/recvbuff.h
+@@ -91,7 +91,7 @@
+
+ /* signal safe - no malloc */
+ extern struct recvbuf *get_free_recv_buffer(void);
+-/* signal unsafe - may malloc */
++/* signal unsafe - may malloc, never returs NULL */
+ extern struct recvbuf *get_free_recv_buffer_alloc(void);
+
+ /* Add a buffer to the full list
+@@ -113,7 +113,7 @@
+ * purge_recv_buffers_for_fd() - purges any previously-received input
+ * from a given file descriptor.
+ */
+-extern void purge_recv_buffers_for_fd(SOCKET);
++extern void purge_recv_buffers_for_fd(int);
+
+ /*
+ * Checks to see if there are buffers to process
+--- contrib/ntp/lib/isc/include/isc/string.h.orig
++++ contrib/ntp/lib/isc/include/isc/string.h
+@@ -199,6 +199,24 @@
+ *
+ */
+
++int
++isc_tsmemcmp(const void *p1, const void *p2, size_t len);
++/*
++ * Lexicographic compare 'len' unsigned bytes from 'p1' and 'p2'
++ * like 'memcmp()'.
++ *
++ * This function is safe from timing attacks as it has a runtime that
++ * only depends on 'len' and has no early-out option.
++ *
++ * Use this to check MACs and other material that is security sensitive.
++ *
++ * Returns:
++ * (let x be the byte offset of the first different byte)
++ * -1 if (u_char)p1[x] < (u_char)p2[x]
++ * 1 if (u_char)p1[x] > (u_char)p2[x]
++ * 0 if byte series are equal
++ */
++
+ char *
+ isc_string_separate(char **stringp, const char *delim);
+
+--- contrib/ntp/lib/isc/hmacmd5.c.orig
++++ contrib/ntp/lib/isc/hmacmd5.c
+@@ -145,5 +145,5 @@
+
+ REQUIRE(len <= ISC_MD5_DIGESTLENGTH);
+ isc_hmacmd5_sign(ctx, newdigest);
+- return (ISC_TF(memcmp(digest, newdigest, len) == 0));
++ return (ISC_TF(isc_tsmemcmp(digest, newdigest, len) == 0));
+ }
+--- contrib/ntp/lib/isc/hmacsha.c.orig
++++ contrib/ntp/lib/isc/hmacsha.c
+@@ -538,7 +538,7 @@
+
+ REQUIRE(len <= ISC_SHA1_DIGESTLENGTH);
+ isc_hmacsha1_sign(ctx, newdigest, ISC_SHA1_DIGESTLENGTH);
+- return (ISC_TF(memcmp(digest, newdigest, len) == 0));
++ return (ISC_TF(isc_tsmemcmp(digest, newdigest, len) == 0));
+ }
+
+ /*
+@@ -551,7 +551,7 @@
+
+ REQUIRE(len <= ISC_SHA224_DIGESTLENGTH);
+ isc_hmacsha224_sign(ctx, newdigest, ISC_SHA224_DIGESTLENGTH);
+- return (ISC_TF(memcmp(digest, newdigest, len) == 0));
++ return (ISC_TF(isc_tsmemcmp(digest, newdigest, len) == 0));
+ }
+
+ /*
+@@ -564,7 +564,7 @@
+
+ REQUIRE(len <= ISC_SHA256_DIGESTLENGTH);
+ isc_hmacsha256_sign(ctx, newdigest, ISC_SHA256_DIGESTLENGTH);
+- return (ISC_TF(memcmp(digest, newdigest, len) == 0));
++ return (ISC_TF(isc_tsmemcmp(digest, newdigest, len) == 0));
+ }
+
+ /*
+@@ -577,7 +577,7 @@
+
+ REQUIRE(len <= ISC_SHA384_DIGESTLENGTH);
+ isc_hmacsha384_sign(ctx, newdigest, ISC_SHA384_DIGESTLENGTH);
+- return (ISC_TF(memcmp(digest, newdigest, len) == 0));
++ return (ISC_TF(isc_tsmemcmp(digest, newdigest, len) == 0));
+ }
+
+ /*
+@@ -590,5 +590,5 @@
+
+ REQUIRE(len <= ISC_SHA512_DIGESTLENGTH);
+ isc_hmacsha512_sign(ctx, newdigest, ISC_SHA512_DIGESTLENGTH);
+- return (ISC_TF(memcmp(digest, newdigest, len) == 0));
++ return (ISC_TF(isc_tsmemcmp(digest, newdigest, len) == 0));
+ }
+--- contrib/ntp/lib/isc/tsmemcmp.c.orig
++++ contrib/ntp/lib/isc/tsmemcmp.c
+@@ -0,0 +1,55 @@
++/*
++ * Copyright (C) 2004-2007, 2011, 2012 Internet Systems Consortium, Inc. ("ISC")
++ * Copyright (C) 1999-2001, 2003 Internet Software Consortium.
++ *
++ * Permission to use, copy, modify, and/or distribute this software for any
++ * purpose with or without fee is hereby granted, provided that the above
++ * copyright notice and this permission notice appear in all copies.
++ *
++ * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
++ * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
++ * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
++ * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
++ * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
++ * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
++ * PERFORMANCE OF THIS SOFTWARE.
++ */
++
++/* $Id$ */
++
++/*! \file */
++
++#include <config.h>
++#include <limits.h>
++#include <isc/string.h>
++
++/* Making a portable memcmp that has no internal branches and loops always
++ * once for every byte without early-out shortcut has a few challenges.
++ *
++ * Inspired by 'timingsafe_memcmp()' from the BSD system and
++ * https://github.com/libressl-portable/openbsd/blob/master/src/lib/libc/string/timingsafe_memcmp.c
++ *
++ * Sadly, that one is not portable C: It makes assumptions on the representation
++ * of negative integers and assumes sign-preserving right-shift of negative
++ * signed values. This is a rewrite from scratch that should not suffer from
++ * such issues.
++ *
++ * 2015-12-12, J. Perlinger (perlinger-at-ntp-dot-org)
++ */
++int
++isc_tsmemcmp(const void *p1, const void *p2, size_t nb) {
++ const unsigned char *ucp1 = p1;
++ const unsigned char *ucp2 = p2;
++ unsigned int isLT = 0u;
++ unsigned int isGT = 0u;
++ volatile unsigned int mask = (1u << CHAR_BIT);
++
++ for (/*NOP*/; 0 != nb; --nb, ++ucp1, ++ucp2) {
++ isLT |= mask &
++ ((unsigned int)*ucp1 - (unsigned int)*ucp2);
++ isGT |= mask &
++ ((unsigned int)*ucp2 - (unsigned int)*ucp1);
++ mask &= ~(isLT | isGT);
++ }
++ return (int)(isGT >> CHAR_BIT) - (int)(isLT >> CHAR_BIT);
++}
+--- contrib/ntp/libntp/Makefile.am.orig
++++ contrib/ntp/libntp/Makefile.am
+@@ -36,6 +36,7 @@
+ $(srcdir)/../lib/isc/unix/time.c \
+ $(srcdir)/../lib/isc/sha1.c \
+ $(srcdir)/../lib/isc/sockaddr.c \
++ $(srcdir)/../lib/isc/tsmemcmp.c \
+ $(NULL)
+
+ if PTHREADS
+--- contrib/ntp/libntp/Makefile.in.orig
++++ contrib/ntp/libntp/Makefile.in
+@@ -182,6 +182,7 @@
+ $(srcdir)/../lib/isc/$(LIBISC_PTHREADS_NOTHREADS)/thread.c \
+ $(srcdir)/../lib/isc/unix/time.c $(srcdir)/../lib/isc/sha1.c \
+ $(srcdir)/../lib/isc/sockaddr.c \
++ $(srcdir)/../lib/isc/tsmemcmp.c \
+ $(srcdir)/../lib/isc/pthreads/mutex.c
+ am__objects_1 =
+ @PTHREADS_TRUE at am__objects_2 = mutex.$(OBJEXT)
+@@ -196,7 +197,7 @@
+ result.$(OBJEXT) stdio.$(OBJEXT) stdtime.$(OBJEXT) \
+ strerror.$(OBJEXT) task.$(OBJEXT) thread.$(OBJEXT) \
+ time.$(OBJEXT) sha1.$(OBJEXT) sockaddr.$(OBJEXT) \
+- $(am__objects_1) $(am__objects_2)
++ tsmemcmp.$(OBJEXT) $(am__objects_1) $(am__objects_2)
+ am__objects_4 = a_md5encrypt.$(OBJEXT) adjtime.$(OBJEXT) \
+ atoint.$(OBJEXT) atolfp.$(OBJEXT) atouint.$(OBJEXT) \
+ audio.$(OBJEXT) authkeys.$(OBJEXT) authreadkeys.$(OBJEXT) \
+@@ -264,6 +265,7 @@
+ $(srcdir)/../lib/isc/$(LIBISC_PTHREADS_NOTHREADS)/thread.c \
+ $(srcdir)/../lib/isc/unix/time.c $(srcdir)/../lib/isc/sha1.c \
+ $(srcdir)/../lib/isc/sockaddr.c \
++ $(srcdir)/../lib/isc/tsmemcmp.c \
+ $(srcdir)/../lib/isc/pthreads/mutex.c
+ am_libntpsim_a_OBJECTS = systime_s.$(OBJEXT) $(am__objects_4)
+ libntpsim_a_OBJECTS = $(am_libntpsim_a_OBJECTS)
+@@ -631,7 +633,8 @@
+ $(srcdir)/../lib/isc/task.c \
+ $(srcdir)/../lib/isc/$(LIBISC_PTHREADS_NOTHREADS)/thread.c \
+ $(srcdir)/../lib/isc/unix/time.c $(srcdir)/../lib/isc/sha1.c \
+- $(srcdir)/../lib/isc/sockaddr.c $(NULL) $(am__append_1)
++ $(srcdir)/../lib/isc/sockaddr.c \
++ $(srcdir)/../lib/isc/tsmemcmp.c $(NULL) $(am__append_1)
+ libntp_a_SRCS = \
+ a_md5encrypt.c \
+ adjtime.c \
+@@ -862,6 +865,7 @@
+ @AMDEP_TRUE@@am__include@ @am__quote at ./$(DEPDIR)/time.Po at am__quote@
+ @AMDEP_TRUE@@am__include@ @am__quote at ./$(DEPDIR)/timetoa.Po at am__quote@
+ @AMDEP_TRUE@@am__include@ @am__quote at ./$(DEPDIR)/timevalops.Po at am__quote@
++ at AMDEP_TRUE@@am__include@ @am__quote at ./$(DEPDIR)/tsmemcmp.Po at am__quote@
+ @AMDEP_TRUE@@am__include@ @am__quote at ./$(DEPDIR)/uglydate.Po at am__quote@
+ @AMDEP_TRUE@@am__include@ @am__quote at ./$(DEPDIR)/vint64ops.Po at am__quote@
+ @AMDEP_TRUE@@am__include@ @am__quote at ./$(DEPDIR)/work_fork.Po at am__quote@
+@@ -1323,6 +1327,20 @@
+ @AMDEP_TRUE@@am__fastdepCC_FALSE@ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
+ @am__fastdepCC_FALSE@ $(AM_V_CC at am__nodep@)$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o sockaddr.obj `if test -f '$(srcdir)/../lib/isc/sockaddr.c'; then $(CYGPATH_W) '$(srcdir)/../lib/isc/sockaddr.c'; else $(CYGPATH_W) '$(srcdir)/$(srcdir)/../lib/isc/sockaddr.c'; fi`
+
++tsmemcmp.o: $(srcdir)/../lib/isc/tsmemcmp.c
++ at am__fastdepCC_TRUE@ $(AM_V_CC)$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT tsmemcmp.o -MD -MP -MF $(DEPDIR)/tsmemcmp.Tpo -c -o tsmemcmp.o `test -f '$(srcdir)/../lib/isc/tsmemcmp.c' || echo '$(srcdir)/'`$(srcdir)/../lib/isc/tsmemcmp.c
++ at am__fastdepCC_TRUE@ $(AM_V_at)$(am__mv) $(DEPDIR)/tsmemcmp.Tpo $(DEPDIR)/tsmemcmp.Po
++ at AMDEP_TRUE@@am__fastdepCC_FALSE@ $(AM_V_CC)source='$(srcdir)/../lib/isc/tsmemcmp.c' object='tsmemcmp.o' libtool=no @AMDEPBACKSLASH@
++ at AMDEP_TRUE@@am__fastdepCC_FALSE@ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++ at am__fastdepCC_FALSE@ $(AM_V_CC at am__nodep@)$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o tsmemcmp.o `test -f '$(srcdir)/../lib/isc/tsmemcmp.c' || echo '$(srcdir)/'`$(srcdir)/../lib/isc/tsmemcmp.c
++
++tsmemcmp.obj: $(srcdir)/../lib/isc/tsmemcmp.c
++ at am__fastdepCC_TRUE@ $(AM_V_CC)$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT tsmemcmp.obj -MD -MP -MF $(DEPDIR)/tsmemcmp.Tpo -c -o tsmemcmp.obj `if test -f '$(srcdir)/../lib/isc/tsmemcmp.c'; then $(CYGPATH_W) '$(srcdir)/../lib/isc/tsmemcmp.c'; else $(CYGPATH_W) '$(srcdir)/$(srcdir)/../lib/isc/tsmemcmp.c'; fi`
++ at am__fastdepCC_TRUE@ $(AM_V_at)$(am__mv) $(DEPDIR)/tsmemcmp.Tpo $(DEPDIR)/tsmemcmp.Po
++ at AMDEP_TRUE@@am__fastdepCC_FALSE@ $(AM_V_CC)source='$(srcdir)/../lib/isc/tsmemcmp.c' object='tsmemcmp.obj' libtool=no @AMDEPBACKSLASH@
++ at AMDEP_TRUE@@am__fastdepCC_FALSE@ DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
++ at am__fastdepCC_FALSE@ $(AM_V_CC at am__nodep@)$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o tsmemcmp.obj `if test -f '$(srcdir)/../lib/isc/tsmemcmp.c'; then $(CYGPATH_W) '$(srcdir)/../lib/isc/tsmemcmp.c'; else $(CYGPATH_W) '$(srcdir)/$(srcdir)/../lib/isc/tsmemcmp.c'; fi`
++
+ mutex.o: $(srcdir)/../lib/isc/pthreads/mutex.c
+ @am__fastdepCC_TRUE@ $(AM_V_CC)$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -MT mutex.o -MD -MP -MF $(DEPDIR)/mutex.Tpo -c -o mutex.o `test -f '$(srcdir)/../lib/isc/pthreads/mutex.c' || echo '$(srcdir)/'`$(srcdir)/../lib/isc/pthreads/mutex.c
+ @am__fastdepCC_TRUE@ $(AM_V_at)$(am__mv) $(DEPDIR)/mutex.Tpo $(DEPDIR)/mutex.Po
+--- contrib/ntp/libntp/a_md5encrypt.c.orig
++++ contrib/ntp/libntp/a_md5encrypt.c
+@@ -10,7 +10,7 @@
+ #include "ntp_stdlib.h"
+ #include "ntp.h"
+ #include "ntp_md5.h" /* provides OpenSSL digest API */
+-
++#include "isc/string.h"
+ /*
+ * MD5authencrypt - generate message digest
+ *
+@@ -92,7 +92,7 @@
+ "MAC decrypt: MAC length error");
+ return (0);
+ }
+- return !memcmp(digest, (const char *)pkt + length + 4, len);
++ return !isc_tsmemcmp(digest, (const char *)pkt + length + 4, len);
+ }
+
+ /*
+--- contrib/ntp/libntp/authkeys.c.orig
++++ contrib/ntp/libntp/authkeys.c
+@@ -30,7 +30,7 @@
+ u_long lifetime; /* remaining lifetime */
+ keyid_t keyid; /* key identifier */
+ u_short type; /* OpenSSL digest NID */
+- u_short secretsize; /* secret octets */
++ size_t secretsize; /* secret octets */
+ u_short flags; /* KEY_ flags that wave */
+ };
+
+@@ -51,12 +51,12 @@
+ #endif /* DEBUG */
+
+ static u_short auth_log2(size_t);
+-static void auth_resize_hashtable(void);
+-static void allocsymkey(symkey **, keyid_t, u_short, u_short,
+- u_long, u_short, u_char *, KeyAccT *);
+-static void freesymkey(symkey *, symkey **);
++static void auth_resize_hashtable(void);
++static void allocsymkey(keyid_t, u_short,
++ u_short, u_long, size_t, u_char *, KeyAccT *);
++static void freesymkey(symkey *);
+ #ifdef DEBUG
+-static void free_auth_mem(void);
++static void free_auth_mem(void);
+ #endif
+
+ symkey key_listhead; /* list of all in-use keys */;
+@@ -93,15 +93,88 @@
+
+ /*
+ * The key cache. We cache the last key we looked at here.
++ * Note: this should hold the last *trusted* key. Also the
++ * cache is only loaded when the digest type / MAC algorithm
++ * is valid.
+ */
+ keyid_t cache_keyid; /* key identifier */
+ u_char *cache_secret; /* secret */
+-u_short cache_secretsize; /* secret length */
++size_t cache_secretsize; /* secret length */
+ int cache_type; /* OpenSSL digest NID */
+ u_short cache_flags; /* flags that wave */
+ KeyAccT *cache_keyacclist; /* key access list */
+
++/* --------------------------------------------------------------------
++ * manage key access lists
++ * --------------------------------------------------------------------
++ */
++/* allocate and populate new access node and pushes it on the list.
++ * Returns the new head.
++ */
++KeyAccT*
++keyacc_new_push(
++ KeyAccT * head,
++ const sockaddr_u * addr
++ )
++{
++ KeyAccT * node = emalloc(sizeof(KeyAccT));
++
++ memcpy(&node->addr, addr, sizeof(sockaddr_u));
++ node->next = head;
++ return node;
++}
+
++/* ----------------------------------------------------------------- */
++/* pop and deallocate the first node of a list of access nodes, if
++ * the list is not empty. Returns the tail of the list.
++ */
++KeyAccT*
++keyacc_pop_free(
++ KeyAccT *head
++ )
++{
++ KeyAccT * next = NULL;
++ if (head) {
++ next = head->next;
++ free(head);
++ }
++ return next;
++}
++
++/* ----------------------------------------------------------------- */
++/* deallocate the list; returns an empty list. */
++KeyAccT*
++keyacc_all_free(
++ KeyAccT * head
++ )
++{
++ while (head)
++ head = keyacc_pop_free(head);
++ return head;
++}
++
++/* ----------------------------------------------------------------- */
++/* scan a list to see if it contains a given address. Return the
++ * default result value in case of an empty list.
++ */
++int /*BOOL*/
++keyacc_contains(
++ const KeyAccT *head,
++ const sockaddr_u *addr,
++ int defv)
++{
++ if (head) {
++ do {
++ if (SOCK_EQ(&head->addr, addr))
++ return TRUE;
++ } while (NULL != (head = head->next));
++ return FALSE;
++ } else {
++ return !!defv;
++ }
++}
++
++
+ /*
+ * init_auth - initialize internal data
+ */
+@@ -139,7 +212,7 @@
+ symkey_alloc * next_alloc;
+
+ while (NULL != (sk = HEAD_DLIST(key_listhead, llink))) {
+- freesymkey(sk, &key_hash[KEYHASH(sk->keyid)]);
++ freesymkey(sk);
+ }
+ free(key_hash);
+ key_hash = NULL;
+@@ -243,7 +316,22 @@
+ return (u_short)r;
+ }
+
++static void
++authcache_flush_id(
++ keyid_t id
++ )
++{
++ if (cache_keyid == id) {
++ cache_keyid = 0;
++ cache_type = 0;
++ cache_flags = 0;
++ cache_secret = NULL;
++ cache_secretsize = 0;
++ cache_keyacclist = NULL;
++ }
++}
+
++
+ /*
+ * auth_resize_hashtable
+ *
+@@ -288,18 +376,21 @@
+ */
+ static void
+ allocsymkey(
+- symkey ** bucket,
+ keyid_t id,
+ u_short flags,
+ u_short type,
+ u_long lifetime,
+- u_short secretsize,
++ size_t secretsize,
+ u_char * secret,
+ KeyAccT * ka
+ )
+ {
+ symkey * sk;
++ symkey ** bucket;
+
++ bucket = &key_hash[KEYHASH(id)];
++
++
+ if (authnumfreekeys < 1)
+ auth_moremem(-1);
+ UNLINK_HEAD_SLIST(sk, authfreekeys, llink.f);
+@@ -323,12 +414,19 @@
+ */
+ static void
+ freesymkey(
+- symkey * sk,
+- symkey ** bucket
++ symkey * sk
+ )
+ {
++ symkey ** bucket;
+ symkey * unlinked;
+
++ if (NULL == sk)
++ return;
++
++ authcache_flush_id(sk->keyid);
++ keyacc_all_free(sk->keyacclist);
++
++ bucket = &key_hash[KEYHASH(sk->keyid)];
+ if (sk->secret != NULL) {
+ memset(sk->secret, '\0', sk->secretsize);
+ free(sk->secret);
+@@ -354,18 +452,16 @@
+ {
+ symkey * sk;
+
+- for (sk = key_hash[KEYHASH(id)]; sk != NULL; sk = sk->hlink) {
+- if (id == sk->keyid) {
++ for (sk = key_hash[KEYHASH(id)]; sk != NULL; sk = sk->hlink)
++ if (id == sk->keyid)
+ return sk;
+- }
+- }
+-
+ return NULL;
+ }
+
+
+ /*
+- * auth_havekey - return TRUE if the key id is zero or known
++ * auth_havekey - return TRUE if the key id is zero or known. The
++ * key needs not to be trusted.
+ */
+ int
+ auth_havekey(
+@@ -372,19 +468,10 @@
+ keyid_t id
+ )
+ {
+- symkey * sk;
+-
+- if (0 == id || cache_keyid == id) {
+- return TRUE;
+- }
+-
+- for (sk = key_hash[KEYHASH(id)]; sk != NULL; sk = sk->hlink) {
+- if (id == sk->keyid) {
+- return TRUE;
+- }
+- }
+-
+- return FALSE;
++ return
++ (0 == id) ||
++ (cache_keyid == id) ||
++ (NULL != auth_findkey(id));
+ }
+
+
+@@ -400,35 +487,25 @@
+ symkey * sk;
+
+ authkeylookups++;
+- if (0 == id || cache_keyid == id) {
+- return TRUE;
+- }
++ if (0 == id || cache_keyid == id)
++ return !!(KEY_TRUSTED & cache_flags);
+
+ /*
+- * Seach the bin for the key. If found and the key type
+- * is zero, somebody marked it trusted without specifying
+- * a key or key type. In this case consider the key missing.
++ * Search the bin for the key. If not found, or found but the key
++ * type is zero, somebody marked it trusted without specifying a
++ * key or key type. In this case consider the key missing.
+ */
+ authkeyuncached++;
+- for (sk = key_hash[KEYHASH(id)]; sk != NULL; sk = sk->hlink) {
+- if (id == sk->keyid) {
+- if (0 == sk->type) {
+- authkeynotfound++;
+- return FALSE;
+- }
+- break;
+- }
++ sk = auth_findkey(id);
++ if ((sk == NULL) || (sk->type == 0)) {
++ authkeynotfound++;
++ return FALSE;
+ }
+
+ /*
+- * If the key is not found, or if it is found but not trusted,
+- * the key is not considered found.
++ * If the key is not trusted, the key is not considered found.
+ */
+- if (NULL == sk) {
+- authkeynotfound++;
+- return FALSE;
+- }
+- if (!(KEY_TRUSTED & sk->flags)) {
*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
More information about the svn-doc-all
mailing list