Date: Fri, 29 Apr 2016 17:09:13 -0700 From: Charles Swiger <cswiger@mac.com> To: Roger Marquis <marquis@roble.com> Cc: freebsd-security <freebsd-security@freebsd.org> Subject: Re: FreeBSD Security Advisory FreeBSD-SA-16:16.ntp Message-ID: <28698FCA-CEAB-4A0F-9F12-57FCCD871E1E@mac.com> In-Reply-To: <0O6F002Z65WLUS40@mr28p00im-smtpin028.me.com> References: <20160429082953.DB31D1769@freefall.freebsd.org> <9e6342a420259fec7bd21d6222cc6e05@zahemszky.hu> <1461929003.67736.2.camel@yandex.com> <CINIP100NTSBSRqf69a0000002a@cinip100ntsbs.irtnog.net> <BABF8C57A778F04791343E5601659908237051@cinip100ntsbs.irtnog.net> <0O6F002Z65WLUS40@mr28p00im-smtpin028.me.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 29, 2016, at 4:43 PM, Roger Marquis <marquis@roble.com> wrote: >>> What are the reasons FreeBSD has not deprecated ntpd in favor of >>> openntpd? >>=20 >> 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. >=20 > 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, >=20 > 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, >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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"). >=20 > 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, --=20 -Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?28698FCA-CEAB-4A0F-9F12-57FCCD871E1E>