A security review of three NTP implementations [LWN.net]

The Core Infrastructure Initiative commissioned security audits of three network time protocol (NTP) implementations (ntpd, NTPSec, and Chrony) and has released the results. "From a security standpoint (and here at the CII we are security people), Chrony was the clear winner between these three NTP implementations. Chrony does not have all of the bells and whistles that ntpd does, and it doesn’t implement every single option listed in the NTP specification, but for the vast majority of users this will not matter. If all you need is an NTP client or server (with or without reference clock), which is all that most people need, then its security benefits most likely outweigh any missing features."

to post comments

openntpd.org

Posted Oct 1, 2017 23:15 UTC (Sun) by cornelio (guest, #117499) [Link] (4 responses)

FWIW, OpenBSD has its own fork.

openntpd.org

Posted Oct 1, 2017 23:36 UTC (Sun) by karkhaz (subscriber, #99844) [Link] (2 responses)

Yes, when I saw the headline I was really hoping that the third implementation to be tested would be OpenNTPD. They're using the same development model as OpenSSH (whereby main development is targeted at OpenBSD, and a different developer patches it to create the 'portable' version), which comes with all of the pros and cons that this model entails. I've been using OpenNTPD on my (Linux) boxes, very happy with it.

openntpd.org

Posted Oct 2, 2017 2:11 UTC (Mon) by josh (subscriber, #17465) [Link]

Likewise. I don't know about chrony, and this report is encouraging, but I personally used to use OpenNTPD myself, back when I ran a full NTP daemon and not just an SNTP client.

openntpd.org

Posted Oct 12, 2017 21:16 UTC (Thu) by jch (guest, #51929) [Link]

Last time I checked, OpenNTPd violated the protocol in ways that may cause synchronisation loops (which might in principle lead to desynchronisation of the whole network, not just of the machine running OpenNTPd). I recommend you avoid it.

openntpd.org

Posted Oct 3, 2017 6:26 UTC (Tue) by rsidd (subscriber, #2582) [Link]

Just a nitpick -- OpenNTPD is not a fork, it's a reimplementation like chrony.

A security review of three NTP implementations

Posted Oct 1, 2017 23:36 UTC (Sun) by zblaxell (subscriber, #26385) [Link] (2 responses)

What are these "not every single option in the NTP specification" options that distinguish NTP servers? Autokey? Obscure MAC formats? Missing data fields? Rate tracking and request limiting?

My Google-fu can't find a concise list. Anything worth the extra exposure?

A security review of three NTP implementations

Posted Oct 2, 2017 2:24 UTC (Mon) by fest3er (guest, #60379) [Link] (1 responses)

https://chrony.tuxfamily.org/comparison.html

A security review of three NTP implementations

Posted Oct 2, 2017 4:48 UTC (Mon) by zblaxell (subscriber, #26385) [Link]

Thanks! I somehow missed that in a forest of not-quite-relevant links.

So TL;DR Chrony has no broadcast/multicast, Autokey, or symmetric ephemeral modes (and at least two of those you don't want anyway). There's different NTP clock driver architecture (clock drivers talk to the server through a socket instead of being built into the server). The query interface is different, both on the network (separate port for queries) and admin tools (but not difficult to adapt--I flipped a couple of servers since reading the parent article).

OTOH Chrony boasts better statistical filters (which compensate for the lack of a clustering algorithm?), better power-saving behavior, better DNS pool behavior, and better tolerance for assorted network problems compared to ntpd and openntpd.

A security review of three NTP implementations

Posted Oct 2, 2017 7:46 UTC (Mon) by cyperpunks (subscriber, #39406) [Link] (1 responses)

Chrony also seems to work way better than ntpd in VMs (for some reason).

A security review of three NTP implementations

Posted Oct 2, 2017 15:58 UTC (Mon) by zdzichu (subscriber, #17118) [Link]

Chrony supports KVM's paravirtualized PTP clock, which gives pretty good accuracy.

A security review of three NTP implementations

Posted Oct 2, 2017 15:15 UTC (Mon) by SEJeff (guest, #51588) [Link]

The most obvious reasons chrony is more secure is its apparent simplicity compared to the legacy mess that is ntpd riddled with ancient landmines and old coding standards. It is one of the reasons they mention security reasons to using chrony in the RHEL7 documentation:

https://access.redhat.com/documentation/en-us/red_hat_ent...

A security review of three NTP implementations

Posted Oct 2, 2017 15:34 UTC (Mon) by smurf (subscriber, #17840) [Link]

Just checked out the Chrony sources and had a look.

This is one of the most well-commented and -assertion-sprinkled code bases I have seen lately. Exemplary.

A security review of three NTP implementations

Posted Oct 3, 2017 4:55 UTC (Tue) by gerv (guest, #3376) [Link]

Just to set the record straight: Mozilla's SOS Fund commissioned and paid for the audits of ntp and ntpsec. We also ran the audit for chrony, although it was paid for by CII.

A security review of three NTP implementations

Posted Oct 5, 2017 0:59 UTC (Thu) by nkiesel (guest, #11748) [Link]

Of course we also have systemd-timesyncd these days which promises even simpler "keep my local clock in sync".

A security review of three NTP implementations

Posted Oct 5, 2017 11:52 UTC (Thu) by dskoll (subscriber, #1630) [Link]

This was a very interesting article. I replaced the standard ntpd with chrony on a large number of machines. Not only was it easy to set up, it also seems to lock onto the time references faster than ntpd. Thanks for this!

A security review of three NTP implementations

Posted Oct 6, 2017 23:45 UTC (Fri) by kjp (guest, #39639) [Link] (1 responses)

So still no way for us people "just running clients" to have smeared leap seconds? :(

A security review of three NTP implementations

Posted Oct 6, 2017 23:52 UTC (Fri) by kjp (guest, #39639) [Link]

nevermind, it appears "smear" isn't what I want, it's "leapsecmode slew" on a client, so time doesn't jump backward. Does that actually work for a normal client, e.g. in ec2?

original article url dead; providing link from wayback machine

Posted Jul 22, 2024 14:59 UTC (Mon) by salewski (subscriber, #121521) [Link]

Here's a link to the original article in the Internet Archive's "Wayback Machine":

"Securing Network Time"
Date published: 2017-09-27
https://web.archive.org/web/20171028123642/https://www.co...

The original article at:

https://www.coreinfrastructure.org/news/blogs/2017/09/sec...

is no longer available. The site redirects to a 404 at openssf.org ("Open Source Security Foundation"), and rummaging around the "Blogs & Resources" there, looks like their content only goes back to October 2020. I don't know if that site actually has any connection to the original 'coreinfrastructure.org' other than owning the domain name.