Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Multiple vulnerabilities released in NTP

support.ntp.org

Post reply on HN
Print view View original

111–120 of 120 posts

Re: Multiple vulnerabilities released in NTP

#111

Post by dfc »

scrollaway wrote: post #105
dfc wrote: post #25

PHK has been working on a rewrite of ntp sponsored by the Linux Foundation. He has posted a couple of entries about his progress so far: http://phk.freebsd.dk/time/20140926.html In the meantime Miroslav's chrony is a good alternative: http://chrony.tuxfamily.org/ If you are looking for the fixed version you can grab 4.2.8 from archive.ntp.org which is still responding to requests: http://archive.ntp.org/ntp4/ntp-4.2/…

systemd also has a minimalistic ntp client. It does not implement the full ntp spec but is sufficient for most desktop and server systems.

While the latter half of your comment is a matter of opinion/taste, the first half is categorically incorrect. systemd-timesync is not a minimalistic ntp client, it is a minimalistic sntp client. But do not take my word for it, the authors made this clear in the announcement:

  > A new "systemd-timesyncd" daemon has been added for synchronizing 
  > the system clock across the network. It implements an SNTP client.
I disagree that systemd-timesync is sufficient for most desktops and servers. We do not even need to go down the rabbit hole of discussing one's required stability/precision/accuracy to see a big problem with the "sufficiency" of systemd for most desktops/servers and the developers acknowledge it a couple sentences later in the announcement they "not bother with the full NTP complexity, focusing on querying time from one remote server and synchronizing the local clock to it." How do you detect falsetickers when you only have one sample? When they decided to ignore all the complexity they also chose to ignore clock drift. Maybe your dekstops/servers come with rubidium standards, but the rest of us have crappy crystals. I like that ntp/chrony decided to address clock drift...

Re: Multiple vulnerabilities released in NTP

#112

Post by cbsmith »

dvanduzer wrote: post #76
cbsmith wrote: post #71

Earlier quoted context omitted.

> The much bigger issue is with hardware that doesn't have a local clock/battery. Ummm, no. NTP normally runs on machines that have a local clock/battery, but which need an established network clock anyway. > Critical initialization code should probably compare uptime with current epoch time if it needs a random seed for a long-use token. Using time as a random seed is probably a mistake in the first place. You could…

The average longevity of a Kerberos ticket makes it the perfect example for this attack vector, actually. Are you familiar with something other than NTP as a time source for devices without CMOS? I have a project that desperately needs crypto without a clock.

If you are really worried, use layer 3 or layer 2 security (say with IPSec) to secure NTP communications.

Yes, there is a bit of a bootstrapping problem, but you can address that with a bootstrapped handshake that sets a clock baseline.

Alternatively, you could just hardwire a radio receiver (like say... a GPS receiver).

Re: Multiple vulnerabilities released in NTP

#113

Post by cbsmith »

dvanduzer wrote: post #77
cbsmith wrote: post #70

Earlier quoted context omitted.

Because any cryptographic implementation worth its salt wouldn't be using even second resolution time, so what your watch says is irrelevant. Also, if I cracked an NTP feed, I'd not use it to know what the server's clock is set to so much as to manipulate the server's clock to all kinds of wonderful effect.

You're misunderstanding the attack vector. The exploit is about precisely controlling the delta between a client and server. There is no problem with using low-resolution time signatures as a cryptographic seed. Using time as an entropy source is only a problem if you sample at a lower resolution than your clock's error rate.

Maybe I wasn't clear, but I was thinking one would manipulate the delta specifically to cause the machine to adjust its clock.

Re: Multiple vulnerabilities released in NTP

#114

Post by xorcist »

agwa wrote: post #107
xorcist wrote: post #95

Earlier quoted context omitted.

For that to work you need to compromise _all_ the NTP servers those servers sync to for an extended period of time (years). It's simply not a realistic attack. NTP does not sync time. NTP measures time drift across groups of servers, and sprinkles in known time. I'm not saying authentication is useless, you should turn it on for your known time sources, but it's not so simple as you make it out to be. Unless you use…

In practice, there are systems that use SNTP or regular NTP with periodic calls to ntpdate. Ubuntu does the latter, by default, and is thus susceptible to the attacks I described,

That's a bug with Ubuntu. That mode of operation is for devices without persistent real time clocks or personal laptops where time isn't that important. If you sync your time at reboots you will screw up ntpd's clock drift calculations.

Re: Multiple vulnerabilities released in NTP

#115

Post by xorcist »

ztnewman wrote: post #109
xorcist wrote: post #98

It is important to know how NTP works before you set it up. Several of the comments seem to be misguided. NTP is a peer-to-peer protocol, there are no such thing as an "NTP server" or an "NTP client". NTP measures clock drift over a server group. It discovers enough about your topology to assign a statistical factor to each peer, so that a rogue or broken server can not bring down the whole group. Known good time (wh…

You wouldn't consider a server at stratum 0 and NTP server?

Dedicated ntp peers are often called servers. It's not strictly true in the client/server protocol architecture sense.

Re: Multiple vulnerabilities released in NTP

#116

Post by talideon »

nknighthb wrote: post #110
phkamp wrote: post #104

Earlier quoted context omitted.

First, all functionality included, NTPD is presently 363.000 lines of .c and .h files. Second, the 100.000 is my guesstimate of what is necessary for "core functionality" and I think that is still a pretty staggering size for what that "core functionality" is. There is a lot of ancient infrastructure which complicates otherwise very simple tasks, some design-choices, perfectly valid in 1980 should have been revisited…

I really have no interest in this. You're being incredibly defensive and looking for reasons to argue with someone you don't fundamentally disagree with about trivial crap. For someone who professes to be so busy, that's very strange.

I would guess that PHK, being PHK, is just being thorough rather than defensive. After all, if you can avoid a lot of back and forth, you're saving everybody time. Of all people here, he's definitely one of the ones worth giving the benefit of the doubt.

Re: Multiple vulnerabilities released in NTP

#117

Post by wglb »

nknighthb wrote: post #110
phkamp wrote: post #104

Earlier quoted context omitted.

First, all functionality included, NTPD is presently 363.000 lines of .c and .h files. Second, the 100.000 is my guesstimate of what is necessary for "core functionality" and I think that is still a pretty staggering size for what that "core functionality" is. There is a lot of ancient infrastructure which complicates otherwise very simple tasks, some design-choices, perfectly valid in 1980 should have been revisited…

I really have no interest in this. You're being incredibly defensive and looking for reasons to argue with someone you don't fundamentally disagree with about trivial crap. For someone who professes to be so busy, that's very strange.

Observing this discussion, I read him as being explanatory in great detail. Which I am finding interesting.

And he certainly know more about the ntpd family than I.

Re: Multiple vulnerabilities released in NTP

#118

Post by gpvos »

nknighthb wrote: post #110
phkamp wrote: post #104

Earlier quoted context omitted.

First, all functionality included, NTPD is presently 363.000 lines of .c and .h files. Second, the 100.000 is my guesstimate of what is necessary for "core functionality" and I think that is still a pretty staggering size for what that "core functionality" is. There is a lot of ancient infrastructure which complicates otherwise very simple tasks, some design-choices, perfectly valid in 1980 should have been revisited…

I really have no interest in this. You're being incredibly defensive and looking for reasons to argue with someone you don't fundamentally disagree with about trivial crap. For someone who professes to be so busy, that's very strange.

"I would have written a shorter letter, but I did not have the time." -- Blaise Pascal

Re: Multiple vulnerabilities released in NTP

#119

Post by gpvos »

nknighthb wrote: post #103
phkamp wrote: post #101

Earlier quoted context omitted.

Apologies for being a bit terse, but I've got stuff to do, including buying X-mas presents for my family :-) I've already written about most of this in my little "time-blog" related to this project: http://phk.freebsd.dk/time/index.html Feel free to ask any questions not already answered there. Right now ntimed is less than 4KLOC and while it isn't complete yet, it does contain precision timekeeping, a data collector…

You're defending a lot of stuff I didn't attack. Almost everything you're doing sounds good to me, and I have no idea why you would think otherwise. The only point I made was that 100,000 lines is not staggering for all of the functionality ntpd encompasses, which goes way beyond just "query and steer". I didn't say a typical NTP client should be 100,000 lines. 10,000 lines sounds far, far too large to me, in fact, f…

I think phkamp's words relevant for you are:

> aimed at being part of a larger family of time-keeping programs, like I intend to deliver

I am guessing that ntimed-client is intended for the 99.99% use case for most offices, homes and internet providers (which is client-server, not peer-to-peer), and that another program in the family will provide for your use case, which sounds very advanced to me.

Re: Multiple vulnerabilities released in NTP

#120

Post by lawnchair_larry »

rian wrote: post #99
lawnchair_larry wrote: post #84

Earlier quoted context omitted.

No, rewriting things in memory safe languages is absolutely something that should be done where it makes sense. There is no good reason to write things like ntpd in C anymore. Anyone who says you'll just have a new set of similar issues is full of crap. You'll likely have issues, but ruling out memory corruption out the door is an indisputable win.

Well, there are still some good reasons to write things in C. For one it's standardized. Two it's ubiquitous. I agree that projects should have a way to verify with 100% accuracy the memory safety of their code. One way to do that is to rewrite in another language. Another way to do that is to use a static analyzer that lists out all unsafe operations in your codebase. Here's one http://goto.ucsd.edu/csolve/ . Adds a…

You don't seem to understand this problem space.
Post reply on HN