Following a new security vulnerability in the Network Time Protocol software package, Apple has provided a software update for Mountain Lion and newer versions of OS X.

As usual, the older versions of OS X that one may be stuck with (because the hardware does not support newer versions, because one needs Rosetta, …) are not covered by the security update.

My questions are:

  • is disabling “set date and time automatically” in Software Preferences enough to ensure that ntpd is not running?

  • what might break if the ntdp binary was simply deleted for safety on OS X Snow Leopard or Lion?

In doubt I might use these instructions to limit the scope of ntpd without completely disabling/deleting it, but in this case there remains the risk of getting it wrong and leaving ntpd exposed.

  • Please report this lack of security fix of versions customers are still using to Apple. → apple.com/feedback/macosx.html . They don't have a security feedback entry yet :(.
    – dan
    Commented Dec 23, 2014 at 12:57
  • 1
    @danielAzuelos I went as far as writing a blog post: blog.frama-c.com/index.php?post/2013/01/01/… Commented Dec 23, 2014 at 17:43
  • 1
    @PascalCuoq offtopic: You might revive that iMac with converting it to hackintosh with NUC) — google.com.ua/… Thought I don't know if 17" worth the trouble. Yet 20" definitely does
    – iskra
    Commented Dec 29, 2014 at 1:45

3 Answers 3


is disabling “set date and time automatically” in Software Preferences enough to ensure that ntpd is not running?


Here is the way to insure yourself of this. Open a Terminal or xterm window.

Run the following command:

ps ax | grep ntp

and notice that you have an ntpd process running.

Open System Preferences and turn off Set date and time automatically:

Check with the ps command above that you don't have any ntpd process running.

Don't remove the ntpd binary, this is not necessary and would deprive you of the chance to take advantage of a fix from Apple :).

In doubt I might use these instructions to limit the scope


This receipe will leave you with a running ntpd and hence exposed to an attack.

  • 1
    For some reason unchecking "set date and time automatically" did not kill the ntpd process for me. I had to run: sudo launchctl unload /System/Library/LaunchDaemons/org.ntp.ntpd.plist
    – user12719
    Commented Dec 26, 2014 at 2:15
  • 2
    The command you used is exactly what the GUI of System Preferences is doing. When using it, you should check with a tail -f /var/log/system.log what might be going wrong within your System Preferences. To investigate this problem I advise you to launch another question.
    – dan
    Commented Dec 26, 2014 at 15:54

Instead of disabling ntpd, you should download the source for version 4.2.8 of ntp and compile it yourself. All you need is Xcode for Lion/SnowLeo. It should work on 10.6.x and 10.7.x just fine.

I have updated my 10.10 install immediately after the CVE was made public and source code released and I didn't wait on Apple to release the update.

To compile ntpd, download the source from ntp.org and apply the patch for OS X/FreeBSD. After applying this patch, you will be able to just run "./configure && make." Then you can copy the binaries to appropriate directories (/usr/sbin/ and /usr/bin/).

For Mac OS X 10.7 (Lion):

mkdir ntpd-fix
cd ntpd-fix
curl http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-4.2.8.tar.gz | tar zxf -
cd ntp-4.2.8/ntpd
curl http://bugs.ntp.org/attachment.cgi?id=1165 | patch -p1
cd ..
./configure && make

Here's the list of files and folders to which they belong to that will be built from the source above. After compilation, all these files will be in various sub-folders.


Rename old ones using something like:

sudo mv /usr/sbin/ntpd /usr/sbin/ntpd.old

and then move the new one in. Make sure to chown the files after moving them in place:

sudo chown root:wheel /usr/sbin/ntpd

Note: I did not use sudo make install because I didn't trust the Makefile (I wasn’t sure it would place files in the same folders that Apple has originally placed them in and wanted to be sure they're still in the same spot as old ones). Manually moving 6 files is not a big issue. Rest of the files (man pages, html pages, etc are the same so you don't have to bother moving those.)

  • please add which files have to be copied and where to
    – klanomath
    Commented Dec 23, 2014 at 23:43
  • @klanomath I just edited my comment with more info. Let me know if you run into any issues.
    – MelB
    Commented Dec 24, 2014 at 1:11
  • i added the rest and 10 points ;-)
    – klanomath
    Commented Dec 24, 2014 at 1:28
  • what about ntpsnmpd?
    – klanomath
    Commented Dec 24, 2014 at 1:44
  • 1
    For those who don't want to do manual replacements, it should suffice to run ./configure --prefix='/usr' as the initial step and then follow up with make ; sudo make install. Commented Dec 24, 2014 at 5:00
  1. I've not dug into the documentation of the breach in detail. Normally ntp makes periodic queries to servers to get a correction. Once the drift of the local clock is established these queries aren't frequent.

  2. Most firewalls are configured to ignore request packets from the outside. Ntp I think uses UDP which is nominally stateless. Typically a firewall will let a UDP packet back in for a small window of time after a UDP packet has gone out. The return packet has to be from the right IP, and have the correct port. A black hat would have to either subvert your DNS server or subvert your NTP server.

So would someone explain how this threat is actually put into play, assuming that the person doesn't specify pool.ntp.org as his ntp server?

Ways around this:

  1. Build from source -- above.
  2. Use mac ports. This makes the installation fairly painless, although the initial build will take substantial time and a fair chunk of space. More information https://www.macports.org/

You can also use Fink or Homebrew this way, but MacPorts seems to be less dependent on Apple OS, so in the long run for an older system I suspect there will be less pain.

  1. Configure a non-vulnerable machine to be a local ntp server. Point vulnerable machines to the ntp server. At your firewall block both outbound and inbound for ntp for all but the ntpserver machine. When I ran a local school network, I had one machine (freebsd) that ran a bunch of network services, including ntp. It would then broadcast a single ntp packet every 64 seconds.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .