the NTPd packet-o-death exploits

October 27th 2015 · 2 min read · security, alert, ntp
By Victor Yodaiken

boat When we began implementing the NTP protocol from scratch we found that after 30 years of sometimes smart and sometimes not-so-smart development, there were a number of security issues that we needed to address. Some of these are identified by Boston University researchers in their recent note on NTPd exploits. TimeKeeper is not vulnerable to any of those exploits and the reasons why show what happens when systems are designed from the start with security in mind.

I have to repeat my regular caution that NTPd is a program implementing NTP the protocol. That easily overlooked d is the source of much confusion. The most dangerous of the newly disclosed NTPd flaws is from a mechanism that was designed to allow a NTP source (a network clock) to tell a client computer to back off on time requests perhaps because the source computer is failing or it is overloaded or the client is sending too many requests. This kind of makes sense, but the suggested implementation is really naive. The computer receiving these requests is not required to check that they come from the source or that they are reasonable. So an unrelated computer can send an NTP client a command to never ask for the time again or to only ask once a year and the NTP client may just do it. TimeKeeper is not so trusting. We’ll ignore commands that don’t come from the source itself and we apply reasonableness tests to commands that come from the source. If TimeKeeper gets a message from, even from the source, telling us to not make a time request for a year, TimeKeeper will consider that unreasonable and move on.

The Internet was originally a closed system that didn’t need much security. Security is hard to do well - really hard. So designers of the timing protocols didn’t worry too much about security. This is perhaps even more true for PTP than NTP - the PTP specification is riddled with security holes. We’ve wrapped the protocols in security mechanisms appropriate for the environments that we deploy in. We will improve that work as those environments evolve and TimeKeeper gets deployed into more environments. Security is a moving target and doing it well takes a lot of work and thought. It should not be a surprise that a 30 year old system designed for a more trusting time has a lot of gaps.

“De Windstoot - A ship in need in a raging storm (Willem van de Velde II, 1707)” by Willem van de Velde the Younger - Rijksmuseum, Amsterdam. SK-A-1848. Licensed under Public Domain via Wikimedia Commons .