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 6 of 12 last Next
  • by Anwar Shiekh,

    Anwar Shiekh Anwar Shiekh Dec 30, 2014 9:10 AM in response to flatsixracer
    Level 1 (5 points)
    Dec 30, 2014 9:10 AM in response to flatsixracer

    Any chance of making an installer for 10.5 PPC since

     

    http://www.macissues.com/2014/12/24/how-to-manually-patch-ntp-for-os-x-10-6-and- 10-7/

     

    works for 10.5 (I can send the files if you need)

  • by Anwar Shiekh,

    Anwar Shiekh Anwar Shiekh Dec 30, 2014 10:34 AM in response to Anwar Shiekh
    Level 1 (5 points)
    Dec 30, 2014 10:34 AM in response to Anwar Shiekh

    I don't really know what I am doing but I have cooked something up with XCode's PackageMaker

  • by lenn5,

    lenn5 lenn5 Dec 30, 2014 10:48 AM in response to flatsixracer
    Level 4 (2,531 points)
    Dec 30, 2014 10:48 AM in response to flatsixracer

    I set the time to manual by running this in the terminal. How do I get it back to update automatically?

    thx

    -- update time manually

    sudo ntpdate -u time.apple.com

  • by flatsixracer,

    flatsixracer flatsixracer Dec 30, 2014 12:54 PM in response to xyzzy-xyzzy
    Level 1 (10 points)
    Dec 30, 2014 12:54 PM in response to xyzzy-xyzzy

    I think the latest version of the ntp installer (ntp 4.2.8 revision 4) is good enough and it beats turning off the "Set date and time automatically" setting.

     

    Note: All previous versions of the ntp-fix installer I posted also worked, but we discovered some system.log entries/warning when start & stopping of the ntp daemon. The latest revision eliminates most of these warnings by changing a few settings in ntp-restrict.conf, expect for the IPV6 which is probably not even used in 10.6.x.

    it looks like Apple is customizing and optimizing the ntp open source code to their needs, but they have great knowledge and resources to do so. it would take Apple very little time to create an updated version of ntp for Snow Leopard with the correct config. But we learned a lot about the ntp daemon in the process, so it's all good.

     

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

  • by WZZZ,

    WZZZ WZZZ Dec 30, 2014 2:27 PM in response to flatsixracer
    Level 6 (13,112 points)
    Mac OS X
    Dec 30, 2014 2:27 PM in response to flatsixracer

    I hope that both of you haven't quit your day jobs for this. Many thanks

  • by RobBT,

    RobBT RobBT Dec 30, 2014 2:56 PM in response to flatsixracer
    Level 1 (76 points)
    Dec 30, 2014 2:56 PM in response to flatsixracer

    flatsixracer wrote:

     

    (...)

    Note: All previous versions of the ntp-fix installer I posted also worked, but we discovered some system.log entries/warning when start & stopping of the ntp daemon. The latest revision eliminates most of these warnings by changing a few settings in ntp-restrict.conf, expect for the IPV6 which is probably not even used in 10.6.x.

    (...)

     

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

    Thanks again flatsixracer and thank you too xyzzy-xyzzy. All this work is very much appreciated over here.

  • by WZZZ,

    WZZZ WZZZ Dec 30, 2014 4:24 PM in response to flatsixracer
    Level 6 (13,112 points)
    Mac OS X
    Dec 30, 2014 4:24 PM in response to flatsixracer

    Just installed the rev 4. Logs (seems to be looking good):

     

    ****Dec 30 19:10:34 **** ntpd[282]: proto: fuzz beneath 0.125 usec
    Dec 30 19:10:34 **** org.ntp.ntpd[282]: 30 Dec 19:10:34 ntpd[282]: proto: precision = 1.000 usec (-20)
    Dec 30 19:10:34 **** org.ntp.ntpd[282]: 30 Dec 19:10:34 ntpd[282]: proto: fuzz beneath 0.125 usec
    Dec 30 19:10:34 **** org.ntp.ntpd[282]: 30 Dec 19:10:34 ntpd[282]: Listen and drop on 0 v6wildcard [::]:123
    Dec 30 19:10:34 **** org.ntp.ntpd[282]: 30 Dec 19:10:34 ntpd[282]: Listen and drop on 1 v4wildcard 0.0.0.0:123
    Dec 30 19:10:34 **** org.ntp.ntpd[282]: 30 Dec 19:10:34 ntpd[282]: Listen normally on 2 lo0 [::1]:123
    Dec 30 19:10:34 **** org.ntp.ntpd[282]: 30 Dec 19:10:34 ntpd[282]: Listen normally on 3 lo0 [fe80::1%1]:123
    Dec 30 19:10:34 **** org.ntp.ntpd[282]: 30 Dec 19:10:34 ntpd[282]: setsockopt IPV6_MULTICAST_IF 0 for fe80::1%1 fails: Can't assign requested address
    Dec 30 19:10:34 **** org.ntp.ntpd[282]: 30 Dec 19:10:34 ntpd[282]: Listen normally on 4 lo0 127.0.0.1:123
    Dec 30 19:10:34 **** ntpd[282]: setsockopt IPV6_MULTICAST_IF 0 for fe80::1%1 fails: Can't assign requested address
    Dec 30 19:10:34 **** org.ntp.ntpd[282]: 30 Dec 19:10:34 ntpd[282]: Listen normally on 5 en1 192.168.1.47:123
    Dec 30 19:10:34 **** org.ntp.ntpd[282]: 30 Dec 19:10:34 ntpd[282]: Listening on routing socket on fd #26 for interface updates
    Dec 30 19:11:28 **** ntpd[290]: ntpd 4.2.8@1.3265-o Wed Dec 24 18:19:07 UTC 2014 (1): Starting
    Dec 30 19:11:28 **** org.ntp.ntpd[290]: 30 Dec 19:11:28 ntpd[290]: ntpd 4.2.8@1.3265-o Wed Dec 24 18:19:07 UTC 2014 (1): Starting
    Dec 30 19:11:28 **** org.ntp.ntpd[290]: 30 Dec 19:11:28 ntpd[290]: Command line: /usr/sbin/ntpd -c /private/etc/ntp-restrict.conf -n -g -p /var/run/ntpd.pid -f /var/db/ntp.drift

     

    Question: upon going from manual to automatic, in Little Snitch network monitor, seeing quick connection to sntp, then to ntpd. Wondering what that's about. Hadn't seen that before.

  • by WZZZ,

    WZZZ WZZZ Dec 30, 2014 5:00 PM in response to WZZZ
    Level 6 (13,112 points)
    Mac OS X
    Dec 30, 2014 5:00 PM in response to WZZZ

    Question: upon going from manual to automatic, in Little Snitch network monitor, seeing quick connection to sntp, then to ntpd. Wondering what that's about. Hadn't seen that before.

    SNTP is a reduced version of the NTP protocol that can be used to replace TIME clients.

     

    http://wiki.tcl.tk/3391

     

    Why is it doing this in the rev4? Wasn't with the command line version.

  • by flatsixracer,

    flatsixracer flatsixracer Dec 30, 2014 7:08 PM in response to WZZZ
    Level 1 (10 points)
    Dec 30, 2014 7:08 PM in response to WZZZ

    WZZZ - this may have changed when we corrected the sntp parameter in ntpd-wrapper. Before this change sntp was failing. It's  working as if should, but it is a newer version of ntp and some different behavior is expected. It's very difficult to cover all scenarios. I'd say since we  replaced the ntp related binaries, that it is safe to allow ntpd and sntp traffic on "little snitch".

     

    The incoming traffic request I don't fully understand (which was mentioned above), but I don't have that problem nor was I able to reproduce it being behind two active firewalls (the OS X and Airport Extreme).

     

    --- ntpd-wrapper version <= 4.2.4 (BEFORE)

    ...

    > 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

    ...


    --- ntpd-wrapper version >= 4.2.6 (AFTER

    ...

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

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

    ...


  • by WZZZ,

    WZZZ WZZZ Dec 30, 2014 8:38 PM in response to flatsixracer
    Level 6 (13,112 points)
    Mac OS X
    Dec 30, 2014 8:38 PM in response to flatsixracer

    I think you may be misunderstanding what I said. This was the Little Snitch network monitor, a small splash screen where active outgoing connections or connections history are reported. It was not a prompt from LS to allow or deny. The connection to sntp was allowed, via protected rules in the LS rules--an area entirely different from the network monitor, to allow both ntpd and sntp connections (UDP to Port 123 / ntp) I saw that, upon resuming automatic from manual in date and time, there was a very brief outgoing connection to sntp. It lasted maybe less than a second, then ntdp took over, whereupon the sntp connection became greyed out and then showed as "terminated." It finally disappeared entirely.

     

    If this is now expected behavior, behavior which you consider normal according to the way the installer has been rewritten, then I have no concerns. I was just surprised at seeing this, since I had never seen it before and I wondered what was creating this new behavior. In fact, since LS has protected rules (meaning rules which are set by default, but which can be overridden if necessary) both for ntpd and sntp, then I suppose this is sometimes, at least, expected behavior-- Below is a screenshot from my LS network monitor in 10.8.5.  Also note that my LS is responsible only for outgoing connections. There is a newer version which can define both outgoing and incoming, but that's not the case here.

     

    In fact, scratch all that about whether this should be happening or not: As a test, I just went from manual to auto in 10.8.5, something I never do there, with the network monitor displayed, which it usually isn't, and it did the exact same thing as described above. Quickly connected to sntp and then ntpd took over. It happens very quickly, so I can't even take a screenshot of it to show you. This is obviously completely normal.

    Screen Shot 2014-12-30 at 11.05.40 PM.png

  • by xyzzy-xyzzy,

    xyzzy-xyzzy xyzzy-xyzzy Dec 30, 2014 9:13 PM in response to WZZZ
    Level 1 (10 points)
    Dec 30, 2014 9:13 PM in response to WZZZ

    I am not sure I understand what you are (or where) confused about.  Look at the tail end of the ntpd-wrapper:

     

    - - -

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

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

        break

        else

        logger -p daemon.err -f ${LOG}

        fi

    done

     

    exec /usr/sbin/ntpd -c /private/etc/ntp-restrict.conf -n -g -p /var/run/ntpd.pid -f /var/db/ntp.drift

     

    You see the sntp call (in a loop for each ntp server -- we have only the one specified in Date&Time) followed by the ntpd call which is exactly what you are seeing.

  • by WZZZ,

    WZZZ WZZZ Dec 31, 2014 6:02 AM in response to xyzzy-xyzzy
    Level 6 (13,112 points)
    Mac OS X
    Dec 31, 2014 6:02 AM in response to xyzzy-xyzzy

    I realized--posted in bold and a larger font at the bottom of my reply--upon checking that behavior in my ML, that it was normal (I guess you didn't see that). Especially, since it appears that you are now using the ML ntpd-wrapper. And many thanks to you for all the work you've put in on this.

     

    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

  • by WZZZ,

    WZZZ WZZZ Dec 31, 2014 9:23 AM in response to xyzzy-xyzzy
    Level 6 (13,112 points)
    Mac OS X
    Dec 31, 2014 9:23 AM in response to xyzzy-xyzzy

    I had, yesterday evening (my comments above were related to that) installed the rev 4 on a "virgin" external partition which still had the original 4.2.4. Just now, installed the rev 4 on the internal drive and got this ntpd crash, which I can't reproduce, so I'm assuming it was a one-off event due to the fact that the new rev 4 being installed was overwriting the pre-exisitng 4.2.8 files from flatsixracer's original command line version, which I installed there way back at the beginning of this thread, much before the installer arrived.

     

    My thinking is that *** error for object 0x10020fe48: incorrect checksum for freed object - object was probably modified after being freed reflects the overwriting of flatsixracer's first command line version that relied on binaries compiled by Xcode, thereby producing the incorrect checksum, which com.apple.TrustEvaluationAgent was made very unhappy by. Otherwise, I'm in the dark about why this crash happened. Other than that, it appears to be performing properly.

     

    What do you think?

     

    Process:        ntpd [128]
    Path:            /usr/sbin/ntpd
    Identifier:      ntpd
    Version:        ??? (???)
    Code Type:      X86-64 (Native)
    Parent Process:  launchd [1]

     

    Date/Time:      2014-12-31 11:19:33.212 -0500
    OS Version:      Mac OS X 10.6.8 (10K549)
    Report Version:  6

     

    Exception Type:  EXC_CRASH (SIGABRT)
    Exception Codes: 0x0000000000000000, 0x0000000000000000
    Crashed Thread:  0  Dispatch queue: com.apple.main-thread

     

    Application Specific Information:
    *** error for object 0x10020fe48: incorrect checksum for freed object - object was probably modified after being freed.

     

    Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
    0  libSystem.B.dylib                0x00007fff87b460b6 __kill + 10
    1  libSystem.B.dylib                0x00007fff87be69f6 abort + 83
    2  libSystem.B.dylib                0x00007fff87bd562d szone_error + 519
    3  libSystem.B.dylib                0x00007fff87b016c6 tiny_free_list_remove_ptr + 158
    4  libSystem.B.dylib                0x00007fff87afec8e szone_free_definite_size + 2005
    5  libcrypto.0.9.8.dylib            0x00007fff841dd3b5 CRYPTO_free + 37
    6  libcrypto.0.9.8.dylib            0x00007fff841d9a4b lh_delete + 203
    7  libcrypto.0.9.8.dylib            0x00007fff8424deae OBJ_NAME_remove + 46
    8  libcrypto.0.9.8.dylib            0x00007fff841d9dbd lh_doall + 77
    9  libcrypto.0.9.8.dylib            0x00007fff8424ddcc OBJ_NAME_cleanup + 60
    10  libcrypto.0.9.8.dylib            0x00007fff8422b1ee EVP_cleanup + 14
    11  ntpd                              0x000000010005077b atexit_ssl_cleanup + 43
    12  libSystem.B.dylib                0x00007fff87b0a37f __cxa_finalize + 214
    13  libSystem.B.dylib                0x00007fff87b0a28c exit + 18
    14  ntpd                              0x0000000100011948 finish + 88
    15  libSystem.B.dylib                0x00007fff87b581ba _sigtramp + 26
    16  ???                              0x00007fff5fbff1a0 0 + 140734799802784
    17  libSystem.B.dylib                0x00007fff87afecdc szone_free_definite_size + 2083
    18  ntpd                              0x0000000100020186 filegen_unregister + 134
    19  ntpd                              0x0000000100033723 uninit_util + 99
    20  libSystem.B.dylib                0x00007fff87b0a37f __cxa_finalize + 214
    21  libSystem.B.dylib                0x00007fff87b0a28c exit + 18
    22  ntpd                              0x0000000100051aa4 exit_worker + 68
    23  ntpd                              0x0000000100051ef4 send_blocking_req_internal + 1092
    24  ntpd                              0x000000010004f57b queue_blocking_request + 187
    25  ntpd                              0x000000010004e5b4 getaddrinfo_sometime + 372
    26  ntpd                              0x0000000100002c8c config_peers + 1036
    27  ntpd                              0x0000000100004ee9 config_ntpd + 6521
    28  ntpd                              0x000000010000792c getconfig + 380
    29  ntpd                              0x000000010001224b ntpdmain + 1707
    30  ntpd                              0x0000000100001374 start + 52

     

    Thread 0 crashed with X86 Thread State (64-bit):
      rax: 0x0000000000000000  rbx: 0x0000000100108000  rcx: 0x00007fff5fbfe798  rdx: 0x0000000000000000
      rdi: 0x0000000000000080  rsi: 0x0000000000000006  rbp: 0x00007fff5fbfe7b0  rsp: 0x00007fff5fbfe798
      r8: 0x0000000000000903  r9: 0x0000000000000000  r10: 0x00007fff87b420fa  r11: 0x0000000000000206
      r12: 0x0000000000000000  r13: 0x000000010020fe48  r14: 0x00000001000d6000  r15: 0x00000001001080c0
      rip: 0x00007fff87b460b6  rfl: 0x0000000000000206  cr2: 0x00007fff70de3008

     

    Binary Images:
          0x100000000 -        0x100091fef +ntpd ??? (???) <79F0785F-B853-3CAF-9049-862F70132304> /usr/sbin/ntpd
        0x7fff5fc00000 -    0x7fff5fc3be0f  dyld 132.1 (???) <29DECB19-0193-2575-D838-CF743F0400B2> /usr/lib/dyld
        0x7fff81e0b000 -    0x7fff81e4aff7  libssl.0.9.8.dylib 0.9.8 (compatibility 0.9.8) <B2E93DEC-2F33-366A-995C-ACA0523D508F> /usr/lib/libssl.0.9.8.dylib
        0x7fff8419b000 -    0x7fff842baff7  libcrypto.0.9.8.dylib 0.9.8 (compatibility 0.9.8) <0CE8D59B-D0C7-1DCE-3654-37F27F61BEFA> /usr/lib/libcrypto.0.9.8.dylib
        0x7fff84f67000 -    0x7fff84f68ff7  com.apple.TrustEvaluationAgent 1.1 (1) <5952A9FA-BC2B-16EF-91A7-43902A5C07B6> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/Tru stEvaluationAgent
        0x7fff8636d000 -    0x7fff8637eff7  libz.1.dylib 1.2.3 (compatibility 1.0.0) <97019C74-161A-3488-41EC-A6CA8738418C> /usr/lib/libz.1.dylib
        0x7fff87af7000 -    0x7fff87cb8fef  libSystem.B.dylib 125.2.11 (compatibility 1.0.0) <9AB4F1D1-89DC-0E8A-DC8E-A4FE4D69DB69> /usr/lib/libSystem.B.dylib
        0x7fff88f9e000 -    0x7fff88fa2ff7  libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) <95718673-FEEE-B6ED-B127-BCDBDB60D4E5> /usr/lib/system/libmathCommon.A.dylib
        0x7fff8a6e8000 -    0x7fff8a709fff  libresolv.9.dylib 41.1.0 (compatibility 1.0.0) <9410EC7F-4D24-6740-AFEE-90405750FAD7> /usr/lib/libresolv.9.dylib
        0x7fffffe00000 -    0x7fffffe01fff  libSystem.B.dylib ??? (???) <9AB4F1D1-89DC-0E8A-DC8E-A4FE4D69DB69> /usr/lib/libSystem.B.dylib

  • by xyzzy-xyzzy,Helpful

    xyzzy-xyzzy xyzzy-xyzzy Dec 31, 2014 12:02 PM in response to WZZZ
    Level 1 (10 points)
    Dec 31, 2014 12:02 PM in response to WZZZ

    When I first started with building my own ntp sources from 4.2.8 I had one mysterious panic crash and some time later one system crash.  I happened to save the crash log for that second crash.  It looks exactly like yours and like you it only happened once (so far).  So I am beginning to think there may be some rare edge condition that may cause the 4.2.8 version to fail (maybe that's why Apple possibly did their own changes to 4.2.6  -- just the minimum to address the security fix as opposed to going to an entirely new source base).

     

    As I said this happened only once so far and I haven't been doing too much testing due to doing other stuff.  Maybe using 4.2.8p1-beta2 is a better idea.  That's what I switched to more recently in testing but it too needs more of that testing.  Personally I haven't yet committed to using any of the 4.2.8's on my primary working system until I am convinced it's 100% safe to do so.  Certainly ntpd hasn't failed in all the years prior to this and now I know of the existence of two similar crashes with 4.2.8.   Makes me a little concerned. :-(

  • by WZZZ,

    WZZZ WZZZ Dec 31, 2014 1:31 PM in response to xyzzy-xyzzy
    Level 6 (13,112 points)
    Mac OS X
    Dec 31, 2014 1:31 PM in response to xyzzy-xyzzy

    Personally I haven't yet committed to using any of the 4.2.8's on my primary working system until I am convinced it's 100% safe to do so.

    So, if your primary working system is 10.6, what are you doing there? You think the 4.2.8, as is, has some intrinsic incompatibility with OSX? I'm at a loss now what to do. Could try the one from MacIssues, Topher Kessler's site, or the GitHub one, but if it's intrinsic to the 4.2.8, then none of those is going to be the solution. And wouldn't want to try out the beta and find myself back at square one.

     

    It's probably too late for this now, since a lot of people have lost the original 4.2.4 after trying out the 4.2.8, in one flavor or another, and way, way above my pay grade, but wondering if someone with the skills could port Apple's patch to the original 10.6  4.2.4, with the necessary modifications, whatever they might be.

     

    This was a mild crash/abort. But a KP is far more serious and, if the 4.2.8 was clearly responsible, that points to system instability. Then again, some KPs can happen just once and never again.

first Previous Page 6 of 12 last Next