Since both ntpd and ntpdate rely on ntp servers, and since the Ubuntu repos have yet to complete an update of ntp to 4.2.8p4 (the version recommended by ntp researchers), I expect this means that both ntpdate and ntpd are vulnerable on my laptop (or at the very least, capable of connecting my laptop to any number of vulnerable ntp servers through either mechanism, so it's not sufficient to just stop ntpd alone).

I don’t feel confident about reviewing code and updating to the new version of ntp 4.2.8p4 myself. At the same time, I would like the packages to remain installed so that when future updates become available in the repos, I will be notified by Software Updater.

So my question is not "How to update?" nor “How to uninstall?”, but rather how do I simply disable or ‘turn off’ both ntpd and ntpdate, so they do not ever run or log any activity, without uninstalling them?”

How do I disable ntpd? suggest I can simply prevent ntpd running at all using

sudo update-rc.d -f ntp remove

and prevent ntpdate running at all by adding exit 0 to /etc/default/ntpdate.

However, I do not know how/where in the file to place the line exit 0.

Do I just use an editor like vi or nano to write in exit 0 on any line without a # comment symbol, and it will be interpreted by the system correctly? Can someone please confirm / elaborate on this solution?

  • You should be able to add the exit 0 to the bottom of the ntpdate file so that the ntpd sees that it exited with 0 which means something to ntpd. Certain scripts and files have different exit codes meaning different things.
    – Terrance
    Feb 5 '16 at 22:39

A miniscule amount of research (locate ntp | grep /etc) led me to /etc/init.d/ntp which starts ntp, and is linked to by the startup scripts in the /etc/rc?.d directories (on my Ubuntu Linux 14.04.3 LTS system, YMMV):

/etc/rc1.d/K77ntp -> ../init.d/ntp
/etc/rc2.d/S23ntp -> ../init.d/ntp
/etc/rc3.d/S23ntp -> ../init.d/ntp
/etc/rc4.d/S23ntp -> ../init.d/ntp
/etc/rc5.d/S23ntp -> ../init.d/ntp

/etc/init.d/ntp contains the lines:


test -x $DAEMON || exit 5

So, a simple sudo chmod -x /usr/sbin/ntpd will keep ntpd from ever running, until the file is replaced by an updated version of ntpd.

Working off the same miniscule amount of research also led me to /etc/network/if-up.d/ntpdate, which contains:

# Check whether ntpdate was removed but not purged; it's useless to wait for 
# it in that case.
if [ ! -x /usr/sbin/ntpdate-debian ] && [ -d /usr/sbin ]; then
    exit 0

So, sudo chmod -x /usr/sbin/ntpdate-debian will keep ntpdate-debian from ever running, until the file is replaced by an updated version of ntpdate-debian.

There are other ntp* files in /usr/sbin, but they are all in either the ntp or ntpdate packages:

$ echo /usr/sbin/ntp*| xargs -n 1 dpkg -S
ntp: /usr/sbin/ntpd
ntpdate: /usr/sbin/ntpdate
ntpdate: /usr/sbin/ntpdate-debian
ntp: /usr/sbin/ntp-keygen
ntp: /usr/sbin/ntptime
ntp: /usr/sbin/ntp-wait

so they will all be replaced when you update the ntp and ntpdate packages. Therefore, you could:

sudo chmod -x /usr/sbin/ntp*

But, the Threat and Risk Analysis part of my mind asks, is this really worth the effort? What is the Threat? Your system could be lied to about the time. What is the Risk? If your laptop thinks it is the incorrect time, what will go wrong? Will the World end? Will you leave work hours later than you want?

I think there are bigger Threats and Risks in areas other than the time-of-day.

As always, YMMV.

  • A miniscule amount of research (my second link) might lead one to at least skim the relevant link above discussing why NTP researchers recommended the update; this bit, for instance, seems to address the question that the Threat and Risk Analysis part of your mind asks: "the attacks can be used to snoop on encrypted traffic or to bypass important security measures such as DNSSEC specification preventing the tampering of domain name system records. The most troubling scenario involves bypassing HTTPS encryption by forcing a computer to accept an expired transport layer security certificate."
    – munr0
    Feb 5 '16 at 23:31
  • Especially the paragraph starting "It's not clear how practical some of the attacks would be in real-world settings. A desktop computer with a clock that was set to a date months or years in the past would almost certainly be easy to detect. And it wouldn't be surprising if the incorrect time would trigger errors from the operating system or other applications.". If it's really a problem for you, you could apt-get purge ntp ntpdate, then download, build, install and configure the version you like. It is FOSS.
    – waltinator
    Feb 5 '16 at 23:43

As with many other software available packaged in the Ubuntu repositories:

Don't go by upstream version numbers alone.

Ubuntu backports security fixes, especially for software in the main repository, including ntp and ntpdate.

In this case, the fixes were backported back in October. See USN-2783-1:

Aanchal Malhotra, Isaac E. Cohen, and Sharon Goldberg discovered that NTP incorrectly handled restarting after hitting a panic threshold. A remote attacker could possibly use this issue to alter the system time on clients. (CVE-2015-5300)

Aanchal Malhotra, Isaac E. Cohen, and Sharon Goldberg discovered that NTP incorrectly handled rate limiting. A remote attacker could possibly use this issue to cause clients to stop updating their clock. (CVE-2015-7704, CVE-2015-7705)

Update instructions

The problem can be corrected by updating your system to the following package version:

  • Ubuntu 15.10: ntp 1:4.2.6.p5+dfsg-3ubuntu8.1
  • Ubuntu 15.04: ntp 1:4.2.6.p5+dfsg-3ubuntu6.2
  • Ubuntu 14.04 LTS: ntp 1:4.2.6.p5+dfsg-3ubuntu2.14.04.5
  • Ubuntu 12.04 LTS: ntp 1:4.2.6.p3+dfsg-1ubuntu3.6

Note these are the CVEs listed in the source for the Ars Technica article you linked to.

When in doubt, look at the Ubuntu Security Notices and the Ubuntu CVE tracker.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.