WZZZ

Q: Snow Leopard users: Turn off automatic date and time in System Preferences immediately

http://arstechnica.com/apple/2014/12/apple-automatically-patches-macs-to-fix-sev ere-ntp-security-flaw/

 

When exploited, the NTP flaw can cause buffer overflows that allow remote attackers to execute code on your system.

What this means is that, if you allow date and time to be set automatically by outside servers, you risk having your computer taken over.

 

This is a critical issue, it's being exploited as we speak, and Apple has not provided the update to Snow Leopard users, only to 10.8/Mountain Lion and above. I strongly doubt Apple will ever get around to issuing an update for Snow Leopard, or they would have already. Chances of that happening are close to zero

Posted on Dec 23, 2014 4:37 PM

Close

Q: Snow Leopard users: Turn off automatic date and time in System Preferences immediately

  • All replies
  • Helpful answers

first Previous Page 5 of 12 last Next
  • by WZZZ,

    WZZZ WZZZ Dec 29, 2014 9:39 AM in response to flatsixracer
    Level 6 (13,112 points)
    Mac OS X
    Dec 29, 2014 9:39 AM in response to flatsixracer

    flatsixracer wrote:

     

    Great. Yes, the sntp -v error was corrected in the newer installer by including the updated ntpd-wrapper with the correct command for sntp:

    ...

    if sntp -K /dev/null -s ${server} &> ${LOG}; then

    ...

    But this doesn't apply in my case, since I never used the installer. Did the update from your first command line directions. See "One theory I have..." in my post above for a possible explanation about why I'm not seeing that error.

     

    EDITED: Btw, will do this soon, but haven't gotten around to testing the 10.4.11/PPC, by setting an incorrect time manually and then seeing if automatic fixes it, but any idea if, " no servers can be used, exiting" (from system log ntpd there) is a fatal message? Sure sounds like it.

  • by Allen Barnella,

    Allen Barnella Allen Barnella Dec 29, 2014 9:30 AM in response to flatsixracer
    Level 2 (155 points)
    Dec 29, 2014 9:30 AM in response to flatsixracer

    Thanks. Nope, I'm not using "Little Snitch". I don't believe there's a entry for ntpd in the Firewall by default, but it appears there after you allow or deny the request. I deleted the entry from my Firewall and I'll see if the request appears again and if it does I'll get a screenshot.

  • by WZZZ,

    WZZZ WZZZ Dec 29, 2014 9:43 AM in response to Allen Barnella
    Level 6 (13,112 points)
    Mac OS X
    Dec 29, 2014 9:43 AM in response to Allen Barnella

    Little Snitch has, by default, a  protected rule allowing ntpd to connect. So even if you had LS, it wouldn't be showing you that allow/deny prompt.

  • by Rachel Reiss,

    Rachel Reiss Rachel Reiss Dec 29, 2014 10:38 AM in response to flatsixracer
    Level 1 (5 points)
    Dec 29, 2014 10:38 AM in response to flatsixracer

    Thank you for the patch! I'm not poking around in log reports, but I checked the version and it is updated, and I'm not seeing any odd messages. Much appreciated!

  • by Rachel Reiss,

    Rachel Reiss Rachel Reiss Dec 29, 2014 12:15 PM in response to Rachel Reiss
    Level 1 (5 points)
    Dec 29, 2014 12:15 PM in response to Rachel Reiss

    I would add that although I have a firewall (Intego's), I have not gotten any requests to override it, so I assume that the firewall permits NTP access.

  • by WZZZ,

    WZZZ WZZZ Dec 29, 2014 3:32 PM in response to WZZZ
    Level 6 (13,112 points)
    Mac OS X
    Dec 29, 2014 3:32 PM in response to WZZZ

    EDITED: Btw, will do this soon, but haven't gotten around to testing the 10.4.11/PPC, by setting an incorrect time manually and then seeing if automatic fixes it, but any idea if, " no servers can be used, exiting" (from system log ntpd there) is a fatal message? Sure sounds like it.

    Update: Despite that ominous message, the 10.4.11 time synching appears to be working properly in all respects.

  • by flatsixracer,

    flatsixracer flatsixracer Dec 29, 2014 6:24 PM in response to xyzzy-xyzzy
    Level 1 (10 points)
    Dec 29, 2014 6:24 PM in response to xyzzy-xyzzy

    I read the reply to xyzzy-xyzzy's bug report at http://bugs.ntp.org/show_bug.cgi?id=2712 and was able to eliminate the mlock() log entries by editing the /etc/ntp.conf as suggested:

     

         server time.apple.com

         rlimit memlock 0

     

     

    I also eliminated the KOD log entries by replacing 'kod' with 'kod limited'  in /etc/ntp-restrict.conf :

     

         restrict default kod limited nomodify notrap nopeer noquery

         restrict -6 default kod limited nomodify notrap nopeer noquery

     

         restrict 127.0.0.1

         restrict -6 ::1

         includefile /private/etc/ntp.conf

     

     

    Note: It's an easy change in to the configuration files, but I added these files to the installer to make it easier. it can just be rerun to make the latest changes.

  • by xyzzy-xyzzy,

    xyzzy-xyzzy xyzzy-xyzzy Dec 29, 2014 6:44 PM in response to flatsixracer
    Level 1 (10 points)
    Dec 29, 2014 6:44 PM in response to flatsixracer

    I've now developed a set of changes to get rid of some of those system.log messages that have been bugging me.  These are the result of my research (i.e., lots of googling) and suggestions in the reply to my ntpd bug report (bug 2712).

     

    1. /usr/libexec/ntpd-wrapper


    Change:

    for server in $(awk '/^server/ {print $2}' /etc/ntp.conf); do

        if sntp -v -r -P no -l /var/run/sntp.pid ${server} &> ${LOG}; then

    to:

    for server in $(awk '/^server/ {print $NF}' /etc/ntp.conf); do

        if sntp -K /dev/null -s ${server} &> ${LOG}; then

     

    This was discussed earlier to use the proper call to sntp to remove the -v error report in the system.log and to make the call actually work.

     

    2. /private/etc/ntp-restrict.conf

     

    Change:

    restrict default kod nomodify notrap nopeer noquery

    restrict -6 default kod nomodify notrap nopeer noquery

    to:

    restrict default kod limited nomodify notrap nopeer noquery

    restrict -6 default kod limited nomodify notrap nopeer noquery

     

    Adding "limited" to the restrict command gets rid of the "restrict default: KOD does nothing without LIMITED" system.log messages.

     

    Add the following line to ntp-restrict.conf (anywhere -- I stuck it at the end):

    # Supppres mlockall() use (and resulting system.log messages) since it is not

    # implemented in OSX

    rlimit memlock 0

     

    Adding rlimit memlock 0 causes ntpd to not try to lock pages.  This will cause ntpd to not try to use mlockall() and thus not report "mlockall(): Function not implemented" messages to the system.log.

     

    Alternatively, instead of adding the rlimit line you could edit confg.h in the ntp sources (after the configure is done of course).  Either remove the #define HAVE_MLOCKALL or add a #undef HAVE_MLOCKALL after it.  With HAVE_MLOCKALL undefined, the ntpd/ntpd.c code using mlockall() is not included and thus again this will avoid the system.log messages.

     

    With these changes, here's what I now see in my system.log when I toggle ntpd off and on via the Date&Time system preferences (I was using ntpd 4.2.8p1-beta2 here, yes, yet another beta):

     

    Dec 29 13:17:10 xxxx ntpd[13300]: ntpd 4.2.8p1-beta2@1.3265-o Mon Dec 29 20:06:09 UTC 2014 (5): Starting
    Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: ntpd 4.2.8p1-beta2@1.3265-o Mon Dec 29 20:06:09 UTC 2014 (5): Starting
    Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Command line: /usr/sbin/ntpd -c /private/etc/ntp-restrict.conf -n -g -p /var/run/ntpd.pid -f /var/db/ntp.drift
    Dec 29 13:17:10 xxxx ntpd[13300]: proto: fuzz beneath 0.077 usec
    Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: proto: precision = 1.000 usec (-20)
    Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: proto: fuzz beneath 0.077 usec
    Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Listen and drop on 0 v6wildcard [::]:123
    Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Listen and drop on 1 v4wildcard 0.0.0.0:123
    Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Listen normally on 2 lo0 [::1]:123
    Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Listen normally on 3 lo0 [fe80::1%1]:123
    Dec 29 13:17:10 xxxx ntpd[13300]: setsockopt IPV6_MULTICAST_IF 0 for fe80::1%1 fails: Can't assign requested address
    Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: setsockopt IPV6_MULTICAST_IF 0 for fe80::1%1 fails: Can't assign requested address
    Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Listen normally on 4 lo0 127.0.0.1:123
    Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Listen normally on 5 en0 192.168.1.68:123
    Dec 29 13:17:10 xxxx ntpd[13300]: setsockopt IPV6_MULTICAST_IF 0 for fe80::ea06:88ff:fecd:4ae9%4 fails: Can't assign requested address
    Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Listen normally on 6 en0 [fe80::ea06:88ff:fecd:4ae9%4]:123
    Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: setsockopt IPV6_MULTICAST_IF 0 for fe80::ea06:88ff:fecd:4ae9%4 fails: Can't assign requested address
    Dec 29 13:17:10 xxxx org.ntp.ntpd[13300]: 29 Dec 13:17:10 ntpd[13300]: Listening on routing socket on fd #27 for interface updates
    
    
    

     

    I am still seeing two ntpd processes and I am sure now that the ntpd command in ntpd-wrapper is forking to produce a child ntpd process.  The child only "lives" for a few minutes leaving just the parent.   What's still bothering me about that is the ntpd call uses a -n argument which means "don't fork".   So I submitted another Bugzilla report on that (bug 2718).  We'll see what comes of that.

     

    --

     

    I've gotten a lot deeper into this ntp stuff than I ever wanted to.

  • by Allen Barnella,

    Allen Barnella Allen Barnella Dec 29, 2014 7:36 PM in response to flatsixracer
    Level 2 (155 points)
    Dec 29, 2014 7:36 PM in response to flatsixracer

    I had the request re-appear and I got screenshots this time:

    Screen shot 2014-12-29 at 10.25.06 PM.png

    and clicking the "?" brings up the following:

    Screen shot 2014-12-29 at 10.25.35 PM.png

    I once again clicked "Deny". As far as I can remember I never saw this request before applying the NTP patch.

  • by xyzzy-xyzzy,

    xyzzy-xyzzy xyzzy-xyzzy Dec 29, 2014 10:01 PM in response to flatsixracer
    Level 1 (10 points)
    Dec 29, 2014 10:01 PM in response to flatsixracer

    flatsixracer wrote:

     

    I read the reply to xyzzy-xyzzy's bug report at http://bugs.ntp.org/show_bug.cgi?id=2712 and was able to eliminate the mlock() log entries by editing the /etc/ntp.conf as suggested:

     

        server time.apple.com

        rlimit memlock 0

     

     

    I also eliminated the KOD log entries by replacing 'kod' with 'kod limited'  in /etc/ntp-restrict.conf :

     

        restrict default kod limited nomodify notrap nopeer noquery

        restrict -6 default kod limited nomodify notrap nopeer noquery

     

        restrict 127.0.0.1

        restrict -6 ::1

        includefile /private/etc/ntp.conf

     

     

    Note: It's an easy change in to the configuration files, but I added these files to the installer to make it easier. it can just be rerun to make the latest changes.

     

    For a moment I was confused how you could reply to the post I was in the process of constructing (the one that followed yours).  At least I was confused until I read it again and saw you were monitoring the bug report and posted while I was constructing my post.

     

    At any rate my summary of suggested changes followed your post.  Notice I placed the rlimit in ntp-restrict.conf and not ntp.conf.  The reason I did this is (a) all the ntpd conf changes are localized to the single ntp-restrict.conf file and (b) I thought I better stay clear of ntp.conf.  The reason for the latter is ntp.conf is where the ntp server is specified and I assume that file is edited/changed/replaced if a user changes the time server in the Date&Time system preferences.  Admittedly I didn't verify that because I figured it wasn't worth the effort.  But if it is changed you might risk loosing the rlimit command if you put it in ntp.conf.

     

    As for bug 2718 I reported about seeing two ntpd processes.  Here's what they said:

    You're seeing the 2nd ntpd process because that's where the DNS resolution of

    time.apple.com is being done. That mechanism is independent of the -n switch.

     

    So I asked whether it's always been that way since I never saw if before I started using 4.2.8.  The response was "yes".  This lead to the speculation that Apple may be doing their own changes to the ntp sources.   That may be why the latest ntp security update from Apple yields a ntpd that still says version 4.2.6 and not 4.2.8.  Just speculating here.

     

    I did toss in a remark questioning the "setsockopt IPV6_MULTICAST_IF..." in the logs.  They couldn't say anything useful on those.  So I guess those log entries stay.  I did check that you probably could get rid of them by adding --enable-ipv6=no to the configure step.  But I am not even going to try.

     

    So that's it then.  I guess that's as far as we (or at least I) go.  I guess time will tell (pun intended, couldn't resist) if everything works!

  • by Schmye Bubbula,

    Schmye Bubbula Schmye Bubbula Dec 30, 2014 6:26 AM in response to WZZZ
    Level 1 (0 points)
    Dec 30, 2014 6:26 AM in response to WZZZ

    flatsixracer, could you add version numbers to your ntp 4.2.8.pkg, such as ntp 4.2.8 version 3.pkg? I'm already confused, and can't confidently match the date of the file on your Google Drive to the date of your posts saying that it's been updated. (We now are on the third version... right?)

  • by WZZZ,

    WZZZ WZZZ Dec 30, 2014 7:32 AM in response to flatsixracer
    Level 6 (13,112 points)
    Mac OS X
    Dec 30, 2014 7:32 AM in response to flatsixracer

    It might be helpful for those who need to find the download link for the installer, if you would repost it again. It's way back several pages by now. Thanks for all the terrific work you guys have been doing.

     

    And, one other thought: it looks like you have been trying to weed out the source of some error messages, which I have the feeling have no, or no significant, impact on the functionality. If that is so, would you say that the current version is in a useable state right now?

  • by Cantelia,

    Cantelia Cantelia Dec 30, 2014 7:46 AM in response to WZZZ
    Level 1 (5 points)
    Dec 30, 2014 7:46 AM in response to WZZZ

    This prepackaged installer looks like a much simpler solution.

    https://github.com/MacMiniVault/NTPUpdateSnowLeopard

  • by WZZZ,

    WZZZ WZZZ Dec 30, 2014 8:25 AM in response to Cantelia
    Level 6 (13,112 points)
    Mac OS X
    Dec 30, 2014 8:25 AM in response to Cantelia

    This is the link for the download

    https://github.com/MacMiniVault/NTPUpdateSnowLeopard/releases/download/1.0/NTPUp dateSnowLeopard.mpkg.zip

     

    Have you tried it? If so, how is it working and what messages do you see if you filter for "ntpd" in system.log?

  • by Roger Wilmut1,

    Roger Wilmut1 Roger Wilmut1 Dec 30, 2014 8:29 AM in response to WZZZ
    Level 9 (78,283 points)
    iTunes
    Dec 30, 2014 8:29 AM in response to WZZZ

    flatsixracer's revised installer is at the original URL:

     

    https://drive.google.com/folderview?id=0BxQCbeIgpA2uVjFiN1h4bGZNQ2c&usp=sharing

     

    It now requires a restart. I've not looked for error messages, but I did try mis-setting the clock and then re-enabling auto time, and it corrected correctly.

first Previous Page 5 of 12 last Next