FreeBSD Security Advisory FreeBSD-SA-16:16.ntp

[FreeBSD Security Advisories]

-----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-----
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"

[ga...@zahemszky.hu]

> 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

Both on an i386 and on an amd64 machine, I got:

====
....
Fetching metadasa signature for 10.3-RELEASE from update5.freebsd.org...
done
Fetching metadata index.... done

The update metadata is correctly signed, but
failed an integrity check.
Cowardly refusing to proceed any further.
====

Both machines are VM-s, upgraded from 10.2.

(Got the same with -s update[23456].freebsd.org, and without -s option.

Zahy < Gabor at Zahemszky dot HU >

[Stari Karp]

On Fri, 2016-04-29 at 13:13 +0200, ga...@zahemszky.hu wrote:
> >
> > 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
> Both on an i386 and on an amd64 machine, I got:
>
> ====
> ....
> Fetching metadasa signature for 10.3-RELEASE from
> update5.freebsd.org... 
> done
> Fetching metadata index.... done
>
> The update metadata is correctly signed, but
> failed an integrity check.
> Cowardly refusing to proceed any further.
> ====
>
> Both machines are VM-s, upgraded from 10.2.
>
> (Got the same with -s update[23456].freebsd.org, and without -s
> option.
>
> Zahy < Gabor at Zahemszky dot HU >
> _______________________________________________

I have the same. I did upgrade FreeBSD 10.2 with freebsd-update to
version 10.3:
freebsd-version -ku
10.3-RELEASE
10.3-RELEASE

FreeBSD 10.3-RELEASE #1: Sun Apr 10 13:48:11 EDT 2016     blabla@morebl
a.bla.net:/usr/obj/usr/src/sys/GENERIC  amd64

freebsd-version -ku

[Roger Marquis]

Despite the risk of beating a dead horse (apologies to non-native
english speakers for the acronym), as I cannot recall discussion of
migrating base, and since replacing ntpd with openntpd has been standard
practice in security-oriented environments for a few years now, perhaps
someone on the sec team could help me with this question:

What are the reasons FreeBSD has not deprecated ntpd in favor of
openntpd?

Roger

>> > 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

[Matthew X. Economou]

Roger Marquis writes:
>
> What are the reasons FreeBSD has not deprecated ntpd in favor of
> openntpd?

While I cannot speak for anyone other than myself, the two simply aren't
equivalent. As a conscious design choice, OpenNTPD trades off accuracy
for code simplicity. It lacks support for NTP authentication, access
controls, reference clocks, multicast/broadcast operation, or any kind
of monitoring/reporting. OpenNTPD is probably closer to rdate than ntpd
in terms of their relative capabilities. I'd rather we keep ntpd in
base as a consequence. The only change I'd suggest would be to alter
the default configuration such that all unauthorized access were blocked
(i.e., set "restrict default ignore" and "restrict -6 default ignore").

Best wishes,
Matthew

--
"The lyf so short, the craft so longe to lerne."

[Glen Barber]

On Fri, Apr 29, 2016 at 01:13:21PM +0200, ga...@zahemszky.hu wrote:
> >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
>

> Both on an i386 and on an amd64 machine, I got:
>
> ====
> ....
> Fetching metadasa signature for 10.3-RELEASE from update5.freebsd.org...
> done
> Fetching metadata index.... done
>
> The update metadata is correctly signed, but
> failed an integrity check.
> Cowardly refusing to proceed any further.

This is being investigated within secteam@.

Glen

[Roger Marquis]

>> What are the reasons FreeBSD has not deprecated ntpd in favor of
>> openntpd?
>
> While I cannot speak for anyone other than myself, the two simply aren't
> equivalent. As a conscious design choice, OpenNTPD trades off accuracy
> for code simplicity.

IIRC openntpd is accurate down to ~100ms. Ntpd does have a lot of
code dedicated to additional accuracy but this is exactly the security
trade-off I want to avoid. Who needs millisecond accuracy anyway?

> It lacks support for NTP authentication,

This is still the case but considering the tiny fraction of ntpd sites
that use encryption and the fact that encryption is not enabled by
default it is not really relevant to FreeBSD.

> access controls, reference clocks, multicast/broadcast operation,

Several reflection vulnerabilities over the past few years have been due
to holes in ntpd's access control so its hard to appreciate their value
or the value of these other little used features.

> or any kind of monitoring/reporting.

This is no longer correct. Openntpd's 'ntpctl' reports are sufficient
for the vast majority of sites.

> OpenNTPD is probably closer to rdate than ntpd in terms of their relative
> capabilities.

Rdate? Really? This is a little over the top don't you think?

> I'd rather we keep ntpd in base as a consequence.

I'm sure the NSA would like it if we all did, considering the order of
magnitude difference in security vulnerabilities and the fact that the
daemon has to run as root.

> The only change I'd suggest would be to alter the default configuration
> such that all unauthorized access were blocked (i.e., set "restrict default
> ignore" and "restrict -6 default ignore").

This is a good idea, perhaps, for those sites that need to run ntpd for
one of the reasons listed above but again, that's a tiny fraction of the
installed base. Most FreeBSD systems only need to query a timehost, not
to be a time server.

One of ntpd's biggest disadvantages is that its udp socket cannot be
disabled i.e., it cannot be configured as just a client (though you can
use ipfw or pf to that effect). Considering the demand for this feature
you have to ask why ntpd hasn't been able to implement it?

Roger

[Charles Swiger]

On Apr 29, 2016, at 4:43 PM, Roger Marquis <mar...@roble.com> wrote:
>>> What are the reasons FreeBSD has not deprecated ntpd in favor of
>>> openntpd?
>>
>> While I cannot speak for anyone other than myself, the two simply aren't
>> equivalent. As a conscious design choice, OpenNTPD trades off accuracy
>> for code simplicity.
>
> IIRC openntpd is accurate down to ~100ms.

Hopefully better, since that is terrible clock accuracy.

> Ntpd does have a lot of code dedicated to additional accuracy but this is
> exactly the security trade-off I want to avoid.

Most of the ntpd security bugs relate to authentication, in part because almost
nobody ever used it. The timing code is more robust.

> Who needs millisecond accuracy anyway?

Cell phones, cell phone towers, computers handling financial transactions, etc.

>> It lacks support for NTP authentication,
>
> This is still the case but considering the tiny fraction of ntpd sites
> that use encryption and the fact that encryption is not enabled by
> default it is not really relevant to FreeBSD.

I'll give you this-- ntp auth is unlikely to be missed by most people.

>> access controls, reference clocks, multicast/broadcast operation,
>
> Several reflection vulnerabilities over the past few years have been due
> to holes in ntpd's access control so its hard to appreciate their value
> or the value of these other little used features.

Any listening network service can be used for reflection attacks.

>> or any kind of monitoring/reporting.
>
> This is no longer correct. Openntpd's 'ntpctl' reports are sufficient
> for the vast majority of sites.

Surely individual sites can make up their own minds about that, right?

>> OpenNTPD is probably closer to rdate than ntpd in terms of their relative
>> capabilities.
>
> Rdate? Really? This is a little over the top don't you think?

Not really. Lack of reference clocks is a big deal, and so is SNTP vs NTP.

>> I'd rather we keep ntpd in base as a consequence.
>
> I'm sure the NSA would like it if we all did, considering the order of
> magnitude difference in security vulnerabilities and the fact that the
> daemon has to run as root.

Most time daemons need root in order to execute adjtime() / adjtimex() / ntp_adjtime().

Systems with a capability model might use something like CAP_SYS_TIME instead;
if present, ntpd can be run without root-- see NetBSD, Solaris, and some Linux flavors.

>> The only change I'd suggest would be to alter the default configuration
>> such that all unauthorized access were blocked (i.e., set "restrict default
>> ignore" and "restrict -6 default ignore").
>
> This is a good idea, perhaps, for those sites that need to run ntpd for
> one of the reasons listed above but again, that's a tiny fraction of the
> installed base. Most FreeBSD systems only need to query a timehost, not
> to be a time server.

Your data for that?

> One of ntpd's biggest disadvantages is that its udp socket cannot be
> disabled i.e., it cannot be configured as just a client (though you can
> use ipfw or pf to that effect). Considering the demand for this feature
> you have to ask why ntpd hasn't been able to implement it?

It's not possible to perform NTP timestamp exchange properly without both sides
listening because you want to determine both the round-trip delay and the clock
offset.

openntpd implements SNTPv4 and not the NTPv4 protocol. The extra sanity checking
in the latter helps detect and mitigate against falsetickers, which is why folks
continue to use NTP and ntpd rather than rdate or SNTP implementations like openntpd.

Regards,
--
-Chuck

[jungle Boogie]

Sent from my iPhone 7.1

On Apr 29, 2016 5:09 PM, "Charles Swiger" <csw...@mac.com> wrote:
>
> On Apr 29, 2016, at 4:43 PM, Roger Marquis <mar...@roble.com> wrote:
>
> > Who needs millisecond accuracy anyway?
>
> Cell phones, cell phone towers, computers handling financial
transactions, etc.
>

And these use cases actually use FreeBSD's generic kernel?

[Roger Marquis]

>> Who needs millisecond accuracy anyway?
>
>Cell phones, cell phone towers, computers handling financial transactions, etc.

I manage security for several dozen FreeBSD computers handling financial
transactions and they all run openntpd in client-only mode. It was the
only way we could avoid an absolute deluge of security incident tickets
from corp scanning (mainly Nessus).

These hosts, as well as cell phone towers, etc may be reasons for
keeping isc ntpd as a port but do not support a case for keeping it in
base.

>> perhaps, for those sites that need to run ntpd for one of the reasons
>> listed above but again, that's a tiny fraction of the installed base. Most
>> FreeBSD systems only need to query a timehost, not to be a time server.
>
> Your data for that?

Are you seriously proposing that most FreeBSD installations need to
serve as timeservers?

> openntpd implements SNTPv4 and not the NTPv4 protocol. The extra sanity checking
> in the latter helps detect and mitigate against falsetickers, which is why folks
> continue to use NTP and ntpd rather than rdate or SNTP implementations like openntpd.

And your data for that? I'd personally be surprised if most devops were
familiar with the differences between SNTPv4 and NTPv4.

OTOH openntpd's ntpd.conf does provide a "constraints from" directive
which will query one or more http/https sites and use the resulting
timestamps to reject ntp responses outside of a range near the
constraint. This is a nice OOB feature not found in base ntpd.

Roger

[Eugene Grosbein]

30.04.2016 7:44, Roger Marquis пишет:

> Are you seriously proposing that most FreeBSD installations need to
> serve as timeservers?

Absolutely. Every LAN router should be capable in supplying NTP service
for its LAN clients, it just needs a way to differentiate its LAN/WAN interfaces
(security zones) to prevent abuse from outer interfaces.

[Julian H. Stacey]

Roger Marquis wrote:
> >> What are the reasons FreeBSD has not deprecated ntpd in favor of
> >> openntpd?
> >
> > While I cannot speak for anyone other than myself, the two simply aren't
> > equivalent. As a conscious design choice, OpenNTPD trades off accuracy
> > for code simplicity.
>

> IIRC openntpd is accurate down to ~100ms. Ntpd does have a lot of

> code dedicated to additional accuracy but this is exactly the security

> trade-off I want to avoid. Who needs millisecond accuracy anyway?

AMD + NFS makes on a LAN. 1/10 second seems insufficient.
( Though one could run a faster less secure NTP on a local LAN
behind a firewall, & a slower more secure NTP on a WAN,
(so a FreeBSD gate would need both NTPs ) ).

Cheers,
Julian
--
Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich http://berklix.eu/jhs/
Mail plain text, No quoted-printable, HTML, base64, MS.doc.
Prefix old lines '> ' Reply below old, like play script. Break lines by 80.
Let Brits in EU vote on Brexit https://petition.parliament.uk/petitions/112142
Lie to companies extorting personal data: Prevent abuse, loss & ID theft.

[Christian Weisgerber]

On 2016-04-29, "Matthew X. Economou" <xeno...@irtnog.org> wrote:

>> What are the reasons FreeBSD has not deprecated ntpd in favor of
>> openntpd?
>
> While I cannot speak for anyone other than myself, the two simply aren't
> equivalent.

OpenNTPD is intended to cover the most common usage scenarios.

The single most common use of NTP is a client that simply gets the
time from a server or set of servers. The second most common use
is a server that fetches the time from other servers and redistributes
it to a bunch of clients. These two scenarios cover what, 99% of
all ntpd users?

(OpenNTPD also has support for reference clocks, but that code uses
OpenBSD's sensor framework and is not portable.)

> As a conscious design choice, OpenNTPD trades off accuracy
> for code simplicity.

There has been no such design choice. OpenNTPD is simply accurate
enough in practice that the matter hasn't really come up.

Accuracy is a complete red herring if you are getting your time
from the Internet, where packet jitter is a few milliseconds anyway.

> It lacks support for NTP authentication, access controls,
> reference clocks, multicast/broadcast operation, or any kind of
> monitoring/reporting.

Only a tiny fraction of NTP users will use any of that.

--
Christian "naddy" Weisgerber na...@mips.inka.de

[Christian Weisgerber]

On 2016-04-29, Roger Marquis <mar...@roble.com> wrote:

>> While I cannot speak for anyone other than myself, the two simply aren't

>> equivalent. As a conscious design choice, OpenNTPD trades off accuracy
>> for code simplicity.
>

> IIRC openntpd is accurate down to ~100ms.

I have no idea where you get that absurd number from. OpenNTPD is
accurate at least down to 1 ms. I don't have better time sources.


$ ntpctl -sa
1/1 peers valid, clock synced, stratum 2

peer
wt tl st next poll offset delay jitter
2001:6f8:124a::8 ntp
* 1 10 1 250s 1506s -0.193ms 0.493ms 0.067ms

[Poul-Henning Kamp]

--------
In message <slrnni9e4l...@lorvorc.mips.inka.de>, Christian Weisgerber w
rites:

>On 2016-04-29, Roger Marquis <mar...@roble.com> wrote:
>
>>> While I cannot speak for anyone other than myself, the two simply aren't
>>> equivalent. As a conscious design choice, OpenNTPD trades off accuracy
>>> for code simplicity.
>>
>> IIRC openntpd is accurate down to ~100ms.
>
>I have no idea where you get that absurd number from. OpenNTPD is
>accurate at least down to 1 ms. I don't have better time sources.

Uhm....

So I hate to be pedantic, but "accurate to 1msec" means:

Clock is UTC+/- 1msec

The "accuracy" you claim, and the numbers you report to
back it up means:

Clock is within 1 msec of half the filtered RTT the chosen peer.

By pure chance your clock might be accurate to 1msec, but you have no
way of knowing from the numbers you report, and it is virtually
impossible to prove without a GPS or similar non-network time source.

If the numbers you report always look like that, it would be correct
to claim that it "can track to within 1msec".

But don't worry: Accuracy is not the important part of timekeeping
anyway.

Stability is far more valuable than accuracy, because you can
compensate inaccuracy with any desired precision, but there is only
the genuine article when it comes to stability.

If your peer-offset is always less than a millisecond, chances are
good that you are yanking your clock around to track changes in
network delay which ruins both stability and accuracy.

The best explanation of all this is John R. Vig's Quartz Tutorial
which is freely available on the web - highly recommended:

http://www.am1.us/Local_Papers/U11625%20VIG-TUTORIAL.pdf

Poul-Henning

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

[Roger Marquis]

Large builds over NFS filesystems, particularly secure NFS (i.e.,
Kerberos) are one the best tests of time synchronization. Clients with
bad clocks can further exercise this not uncommon infrastructure. The
reason you don't typically see build errors even here, IME, is because
the timehosts tend to be shared by and local to both client and server.

Roger

Julian Stacey wrote:
> AMD + NFS makes on a LAN. 1/10 second seems insufficient.
> ( Though one could run a faster less secure NTP on a local LAN
> behind a firewall, & a slower more secure NTP on a WAN,
> (so a FreeBSD gate would need both NTPs ) ).

[Piotr Kubaj]

AFAIK FreeBSD project tries to ship basic tools in pretty much every
area (eg. DNS resolver etc.) that works for 99% of users and if anyone
needs something more advanced, they are welcome to use ports.

That it exactly why BIND was replaced with Unbound and LDNS tools. Why
not go the same way with ntpd? Openntpd is just the same to ntpd as
Unbound is to BIND - a simple tool that works for most users.

[Xin Li]

On 4/29/16 04:13, ga...@zahemszky.hu wrote:
>> 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
>
> Both on an i386 and on an amd64 machine, I got:
>
> ====
> ....
> Fetching metadasa signature for 10.3-RELEASE from update5.freebsd.org...
> done
> Fetching metadata index.... done
>
> The update metadata is correctly signed, but
> failed an integrity check.
> Cowardly refusing to proceed any further.

> ====
>
> Both machines are VM-s, upgraded from 10.2.
>
> (Got the same with -s update[23456].freebsd.org, and without -s option.

There was a nit in the metadata, and this should have been addressed now.

Cheers,

[Ian Smith]

On Sat, 30 Apr 2016 14:27:17 +0000, Poul-Henning Kamp wrote:

[..]

> The best explanation of all this is John R. Vig's Quartz Tutorial
> which is freely available on the web - highly recommended:
>
> http://www.am1.us/Local_Papers/U11625%20VIG-TUTORIAL.pdf

This is one of the best scientific/engineering documents I've ever read;
clearly written, almost painfully thorough and, dare I say, beautiful in
presentation. Like a good novel, I couldn't put it aside, despite large
swathes of it being well over my head.

Thanks!

cheers, Ian

[Mark Felder]

On Wed, May 4, 2016, at 04:25, Ian Smith wrote:
> On Sat, 30 Apr 2016 14:27:17 +0000, Poul-Henning Kamp wrote:
>
> [..]
>
> > The best explanation of all this is John R. Vig's Quartz Tutorial
> > which is freely available on the web - highly recommended:
> >
> > http://www.am1.us/Local_Papers/U11625%20VIG-TUTORIAL.pdf
>
> This is one of the best scientific/engineering documents I've ever read;
> clearly written, almost painfully thorough and, dare I say, beautiful in
> presentation. Like a good novel, I couldn't put it aside, despite large
> swathes of it being well over my head.
>

I agree, this is fantastic!


--
Mark Felder
ports-secteam member
fe...@FreeBSD.org