NTP vulnerability on versions prior to 4.2.8 -- we OK?

That issue pertains to NTP servers, not NTP clients.

This being the general (not just Mavericks) Server forum and the OP asking about OS X Server, I think a little more discussion is warranted.

The OP asked about Mavericks Server, which is not affected. OS X clients are not affected.

But up through OS X Server 10.8, Apple included an NTP Server as part of the Server OS. In 10.6 and 10.7, it was a nice checkbox in the GUI. In 10.8 you had to enable it via the command line. In 10.9 and beyond, it was removed as part of the server services.

So if you're running anything less than Server 10.9, you could indeed be running an NTP Server. If you are running it and you actually need it, you should disable it until you can figure out a way to patch it up to the latest version 4.2.8 that doesn't have this vulnerability. Otherwise just disable it. There is some discussion that the OS X (and other Linux) versions of ntpd aren't affected anyway because they don't use "autokey" functionality, but that's not confirmed so best to disable or patch it.

To see the version of ntpd that you're running, you can go to the Terminal and type "ntpd --version" (note the two hyphens, not just one, before the word "version"). As of Yosemite 10.10.1, you should see the response "ntpd - NTP daemon program - Ver. 4.2.6".

John

Linc Davis wrote:

That issue pertains to NTP servers, not NTP clients.

At best an oversimplification.

Client and server run exactly the same program — ntpd — and differ only in how they are configured. The server accepts both control and time packets; the client is configured to reject control packets

The most serious of the vulnerabilities in the Advisory is a buffer-overflow triggered by a single cleverly-constructed packet. The Advisory doesn't say whether it is a time packet or a control packet that triggers the buffer-overflow. If the former, then both client and server configurations are vulnerable. If the latter, then it depends on whether the overflow occurs before or after the code which rejects control packets.

We don't know, and it is irresponsible to suggest otherwise.

A remote buffer overflow in a dæmon that runs as root is something to treat seriously until we know that the client configuration is, in fact, not vulnerable.

Unless you are running a public NTP server, which you aren't, there is no need to do anything. My comment was not an "oversimplification;" that's arrant nonsense.

Well, the Advisory was pretty sketchy on details, but the NTP site offers more details, including the suggested mitigation: disabling control packets from unfamiliar hosts.

This is good news/bad news.

• On the one hand, it suggests that the client configuration (which rejects all control packets) should be safe.
• On the other hand, it's inherently bad advice, as forging UDP packets, to make the source-IP appear to be a familiar host, is Hacking 101 material. So this mitigation strategy will stop only the laziest of attackers.
• In fact, Apple's "client" configuration (see /etc/ntp-restricted.conf) allows control packets from localhost. A common hacker trick is to send UDP packets with the source-IP set to 127.0.0.1. To be safe, you need to make sure your Firewall rejects such spoofed packets. This is easy enough to do (with the "antispoof" command in the PF firewall), but I don't think it is the default (even in the latest Yosemite).

Unless you are running a public NTP server, which you aren't ...

ps -ax | grep ntp

ntpd is not running on OS X by default. You have to manually check the "Set date and time automatically" checkbox in System Preferences.

In our case it is enabled because we're integrate with Active Directory and the time sync is required for kerberos. The ntpd version installed on OS X (ntpd version 4.2.6) is definitely vulnerable. However, I don't believe any crypto / signing functions are being used either so those vulnerabilities don't apply.

(See: http://tenfourfox.blogspot.com/2014/12/time-time-time-see-whats-become-of-ntpd.h tml)

These are the NTP restrictions (default, I believe) on OS X 10.9.5 (Mavericks):

$ cat /etc/ntp-restrict.conf

# Access restrictions documented in ntp.conf(5) and
# http://support.ntp.org/bin/view/Support/AccessRestrictions
# Limit network machines to time queries only
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

Restrict ... no query is a mitigation for all the newly announced vulnerabilities according to:

http://support.ntp.org/bin/view/Main/SecurityNotice

I believe Macs should be good until Apple provides an updates.

Farhanible wrote:

These are the NTP restrictions (default, I believe) on OS X 10.9.5 (Mavericks):

$ cat /etc/ntp-restrict.conf

# Access restrictions documented in ntp.conf(5) and
# http://support.ntp.org/bin/view/Support/AccessRestrictions
# Limit network machines to time queries only
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

It also says (both on Mavericks and Yosemite):

# localhost is unrestricted

restrict 127.0.0.1

restrict -6 ::1

which is to say that it will accept arbitrary control packets from localhost.

I believe Macs should be good until Apple provides an updates.

Modulo the issue of spoofed UDP packets, with source-IP 127.0.0.1. Since the attack requires only a single packet, such spoofing is more practical than it usually would be. Not an issue over the internet (as such packets would almost certainly get filtered), but it is an issue over a LAN (e.g., the Wifi at your local Starbucks).

I would recommend one of

1. Configuring your PF-firewall to reject such packets (a good idea anyway)

   antispoof log quick for "lo0"

2. Unchecking "Set date and time automatically" in System Preferences.
3. Installing NTP 4.2.8 (requires disabling the "pacemaker" dæmon and editing the last line of /usr/libexec/ntpd-wrapper to point to the new ntpd, so not for the faint-of-heart).

Update:

4. Or you could apply the Security Updated that just appeared in Apple Software Update (something of a record, for Apple, in terms of speed of response). Clearly, they thought this was a critical issue.

Any suggestions as to how to patch 10.6.8? It shows 4.2.4p4, so is vulnerable.

I am using an old Core Duo (not Core 2 Duo) Mac mini as a web server and the latest version it can run is 10.6.8...

Thanks

Link to the Apple Security Update for 10.8 and above: About OS X NTP Security Update - Apple Support

But....from what I'm seeing, Apple's patch didn't change the version of ntpd: it still shows as v4.2.6 ($ ntpd --version), even after restarting the process or the entire machine.

Apple's method of verifying the update ($ what /usr/sbin/ntpd) from their Security Update page does show that the update took place. Not sure why they didn't update the version number, or even if the actual daemon was updated (maybe they did something else, like change the config?)....

Long Lane wrote:

Any suggestions as to how to patch 10.6.8? It shows 4.2.4p4, so is vulnerable.

I am using an old Core Duo (not Core 2 Duo) Mac mini as a web server and the latest version it can run is 10.6.8...

Thanks

Wellll.....might be time to upgrade that bad boy. 10.6.8 is pushing 7 years old and isn't being updated by Apple for security issues like this one, so it's probably time to move on. You can get an updated Mac Mini on eBay that will run 10.8 for under $200: it's time.

But if you insist on taking a wrench to 10.6.8 to try to keep the steam from coming out through the rivets, your best bet is probably MacPorts: they have ntp v4.2.8 all ported and ready for downloading and installation. It's not for the faint of heart: get ready to do some serious Googling and messing around to get it to work. And since it's OS X Server, things can get even weirder. The few I've done have been messy but rewarding in the end. ntp might be easy, or might not.

You can really mess up your system with this kind of thing, so be sure to image your system as-is before you start mucking with it. I suggest turning off all server services, quitting all apps, and using SuperDuper to image it at least twice before starting. Then boot from one of the images and make sure it boots properly before starting.

All that sound like a pain? $200 gets you a new box where Apple does all the work..... ;-)

Long Lane wrote:

Any suggestions as to how to patch 10.6.8? It shows 4.2.4p4, so is vulnerable.

Well, the good news is that Apple didn't introduce its benighted "pacemaker" dæmon until 10.9.x; previous to that, their ntpd was the stock version from ntp.org. So "all" you need to do is download, compile and install ntpd 4.2.8, and you should be good to go.

When I did this (on 10.9.x and 10.10.x), I needed to apply this patch to get it to compile. This is a known bug in 4.2.8. Presumably, it will be fixed in the next release.

After applying the patch,

./configure

make

sudo make install

puts the replacement ntpd in /usr/local/sbin . You need to point to that (in the last line of /usr/libexec/ntpd-wrapper) and restart the dæmon.

Sorry, I don't have an 10.6.x system anymore, so I can't test this out for you. But I imagine that, if you're still running an internet server on 10.6.x, you're used to fending for yourself.

DPr0f wrote: if you're still running an internet server on 10.6.x, you're used to fending for yourself.

By this, can I take it to mean that 10.6.x is only vulnerable to the current NTP exploit if one is running a server on the machine? In other words, if I'm not running any public web servers, FTP servers, etc. on a Snow Leopard machine, I should be relatively safe from the NTP vulnerablilty? Or can I get hacked via the NTP vulnerability by simply connecting my Snow Leopard machine to the Internet or WiFi hotspot and/or going to a website?