Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Question:

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

Just saw this post about an unpatched vulnerability in NTP and wasn't sure what version a Mavericks server would be running. Here's the link:


http://www.zdnet.com/article/major-ntp-security-holes-appears-and-are-being-expl oited/


There are lots of resource links within the post, but I got stuck on the basics -- trying to figure out what version of NTP is running on my server. Can anybody point me in the right direction? From what I can gather, the version of NTP on an Apple server may be different than the vulnerable one, but it's hard to tell.

Posted on

Reply
Question marked as Solved
Answer:
Answer:

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.

Posted on

Question marked as Helpful

Dec 21, 2014 10:37 AM in response to Linc Davis In response to Linc Davis

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

There’s more to the conversation

Read all replies

Page content loaded

Question marked as Helpful

Dec 21, 2014 10:37 AM in response to Linc Davis In response to Linc Davis

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

Dec 21, 2014 10:37 AM

Reply Helpful (1)
Question marked as Solved

Dec 21, 2014 11:47 PM in response to Linc Davis In response to Linc Davis

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.

Dec 21, 2014 11:47 PM

Reply Helpful

Dec 22, 2014 5:40 AM in response to DPr0f In response to DPr0f

Egad. Sorry about the erratic "like" and "solved my question" behavior. This user interface, combined with the behavior of the buttons in the emailed notifications, has me raving like a lunatic. I just wanted to say that DRr0f had a helpful answer, not a solution. Now I can't figure out how to undo that decision.


I think this thread is very helpful and, given this last comment, I'm still wondering whether/how to update to a safe version. If indeed this is a client vulnerability, then probably Apple needs to get cracking on an update across all sorts of places and hopefully we'll see that soon. If it's limited to serving NTP, then I think JohnDCCIU is on the right track -- either stop serving, or patch up the daemon.


Anybody deep enough into this issue to comment on whether this is a client or a server problem?

Dec 22, 2014 5:40 AM

Reply Helpful

Dec 22, 2014 8:01 AM in response to OConnorStP In response to OConnorStP

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).

Dec 22, 2014 8:01 AM

Reply Helpful

Dec 22, 2014 10:12 AM in response to OConnorStP In response to OConnorStP

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.

Dec 22, 2014 10:12 AM

Reply Helpful

Dec 22, 2014 1:07 PM in response to Farhanible In response to Farhanible

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.

Dec 22, 2014 1:07 PM

Reply Helpful

Dec 22, 2014 8:24 PM in response to JohnDCCIU In response to JohnDCCIU

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?)....

Dec 22, 2014 8:24 PM

Reply Helpful

Dec 22, 2014 9:04 PM in response to Long Lane In response to Long Lane

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..... ;-)

Dec 22, 2014 9:04 PM

Reply Helpful

Dec 22, 2014 9:11 PM in response to Long Lane In response to Long Lane

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.

Dec 22, 2014 9:11 PM

Reply Helpful

Dec 23, 2014 3:33 AM in response to DPr0f In response to DPr0f

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?

Dec 23, 2014 3:33 AM

Reply Helpful
User profile for user: OConnorStP

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