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

101–110 of 120 posts

Re: Multiple vulnerabilities released in NTP

#101

Post by phkamp »

nknighthb wrote: post #96
phkamp wrote: post #93

Earlier quoted context omitted.

Actually, you're wrong. Most of that source code is there for different and wrong reasons. It doesn't take much source code to steer your clock precisly, we are talking less than 100 lines. What takes up space is all the "extras" and "nice to haves".

I don't think I am, and you haven't given me any reason to believe I am. Why don't you list some of those "extras" and "nice to haves"? Some of them are probably absolutely critical to my services. All of them are probably critical to somebody's. I don't think you're understanding that I'm not in any way disputing that we need something orders of magnitude smaller for the most common case of a simple desktop or serve…

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 to record simulation input, a simulator to chew on those tracefiles and the real-time clock-steering code.

It really isn't rocket size.

OpenBSD's NTP implementation is similar size, but they sort of threw their hands op on smart clock-steering, opting instead for "KISS" from a security point of view.

The main reason I didn't start from OpenBSD's NTP implementation is that it is not aimed at being part of a larger family of time-keeping programs, like I intend to deliver, so it wouldn't save me any time in the end.

(I'll be proud if OpenBSD adopts my ntimed, but I'll fully understand and accept if they do not.)

Adding support for being a NTP server is mostly a matter of writing code to defend against packet storms (See: http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#D-L...)

Adding refclocks should never happen in the "main" process, but rather they should be separate processes, suitably sandboxed and interfaced via a good simple API. (I have radical plans for this, which will allow refclocks to be implemented in PL/1, REXX or INTERCAL if that's how you roll :-)

But right here, right now, my focus is to get the vast majority of all machines away from running NTPD, purely as a matter of security and robustness, while improving their timekeeping at the same time.

If ntimed-client ever grows above 10KLOC, I've failed that goal.

First preview release of the source code will happen this weekend.

Re: Multiple vulnerabilities released in NTP

#103

Post by nknighthb »

phkamp wrote: post #101
nknighthb wrote: post #96

Earlier quoted context omitted.

I don't think I am, and you haven't given me any reason to believe I am. Why don't you list some of those "extras" and "nice to haves"? Some of them are probably absolutely critical to my services. All of them are probably critical to somebody's. I don't think you're understanding that I'm not in any way disputing that we need something orders of magnitude smaller for the most common case of a simple desktop or serve…

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, for the 80-90% case.

Re: Multiple vulnerabilities released in NTP

#104

Post by phkamp »

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…

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 no later than 2000, far too much duplicated functionality, because people didn't know or couldn't get the other copy working etc.

My initial plan was to do a serious rebuild of the existing code, in deference to Prof. Dave Mills and NTPDs long legacy (probably one the longest running open source projects!), but in the end I had to admit that such a strategy would be inefficient on any relevant metric.

I think I could write a bare-bone NTP client in well less than 1000 lines, but it wouldn't be very user-friendly, net-friendly or clock-friendly.

Usability in particular soaks up space, but we're not in 1980 any more, so there is no excuse for stuff like this any more:

   #define  DEFPROPDELAY    0x00624dd3 /* 0.0015 seconds, 1.5 ms */
But doing this takes some code:

  critter phk> ./ntimed-client -p pll_std_capture_time
  Parameter:
        pll_std_capture_time
  Minimum:
        2.000e+01
  Maximum:
        1.000e+06
  Default:
        3.000e+02
  Description:
        Capture time before stiffning PLL.

        After this many seconds, the PLL will start to stiffen the P
        and I terms to gain noise immunity.  Decreasing risks that
        initial frequency capture is not finished, which will increase
        the offset-excursion.  Increasing just delays this stiffning.

  Failure: Stopping after parameter query.
I don't have a target size for the program, but 5-10.000 lines for a robust, reliable, secure and usable time sync client sounds reasonable to me.

... and that will still be less than 3% of the current NTPD.

Re: Multiple vulnerabilities released in NTP

#105

Post by scrollaway »

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.

Re: Multiple vulnerabilities released in NTP

#106

Post by feld »

feld wrote: post #15
hiphopyo wrote: post #3

Might want to check out OpenBSD's OpenNTPD: http://www.openntpd.org/

I've talked to several developers about the state of NTP daemons and neither OpenNTPD nor DragonflyBSD's dntpd are suitable replacements. Neither of those support NTP Authentication nor do they have all of the required algorithms required for proper timekeeping.

late edit: Might make sense to say "precise" instead of "proper"

Re: Multiple vulnerabilities released in NTP

#107

Post by agwa »

xorcist wrote: post #95
agwa wrote: post #33

Earlier quoted context omitted.

You could circumvent certificate revocations by replaying expired OCSP Staple responses that say a certificate is not revoked. You could also cause expired certificates to be accepted, which limits the utility of short-lived certs as a means of protecting against key compromise. And as hannob said, you can circumvent HSTS by setting the time in the future, causing all HSTS entries to be expired.

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,

Re: Multiple vulnerabilities released in NTP

#108

Post by whistlerbrk »

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…

I never knew how it worked, thanks for that very lucid explanation, I'm sure the devils in the implementation details but nevertheless.

Re: Multiple vulnerabilities released in NTP

#109

Post by ztnewman »

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?

Re: Multiple vulnerabilities released in NTP

#110

Post by nknighthb »

phkamp wrote: post #104
nknighthb wrote: post #103

Earlier quoted context omitted.

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…

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.
Post reply on HN