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

Level 6

13,226 points

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:34 PM

175 replies

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

lenn5

Level 4

2,537 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

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

WZZZ Author

Level 6

13,226 points

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

RobBT

Level 1

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

WZZZ Author

Level 6

13,226 points

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.

WZZZ Author

Level 6

13,226 points

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.

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

...

WZZZ Author

Level 6

13,226 points

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.

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.

WZZZ Author

Level 6

13,226 points

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

WZZZ Author

Level 6

13,226 points

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

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. :-(

WZZZ Author

Level 6

13,226 points

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.

Dec 31, 2014 3:39 PM in response to WZZZ

WZZZ wrote:

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.

10.6.7 actually. I just need to do some more testing on my test copy of my boot. Since I keep the boot drive separate from my home dir drive it's easy to switch and test. I just need to use the stuff for some time before I commit to it. If you (we) see an occasional crash that probably can be lived with. If I see another panic crash (like I said I saw that only once and early on in the testing -- for example, still didn't have the updated ntpd-wrapper at that time) well then I probably won't use the new stuff.

As for an "intrinsic incompatibility with OSX" I doubt it. As I said it may be some rare edge condition due to whatever changes were made to the 4.2.8 release. If so I would expect others on other OS's to start reporting the issue. I don't monitor Bugzilla so I not sure when or if that will happen. If it is Mac specific they I'm guessing it's not specific to Snow Leopard. But I guess we'll never know about that since all OSX's beyond Snow Leopard have their own Apple updaters.

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.

Don't get me started with MacIssues. They apparently want to keep their head in the sand and ignore anything that detracts from their build instructions, which by the way are the conventional configure/make/make install on almost all FSF/gnu-like builds. No magic there. I tried to post over there my findings. The moderator refused the post (never answered my mail way either) so that's when I posted here when I found this thread. I even posted a reference on MacIssues to the thread here. Now it and the majority of posts appear deleted as well.

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.

Yeah, and that's the problem. If Apple did their own specific patches we would need to find the Apple tarball for 4.2.6 and their patches to whatever source files they patched. That or a tarball of the patched sources if Apple posted them some where.

As for being able to revert, never update the OS without a backup to fall back on. In addition I have already copied the original sources involved with the ntp installation so I could always revert that way.

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.

Never saw any of these kind of system crashes in all the time using 10.6.7 (previously 10.6.5). And, yes, as I implied above, this is a "mild" crash :-)

############# HAPPY NEW YEAR TO EVERYONE #############

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