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

81–90 of 120 posts

Re: Multiple vulnerabilities released in NTP

#81

Post by PhantomGremlin »

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.

I'm sure that a good number of people have requirements that OpenNTPD can't satisfy. However, for most home or office users I'm sure it's good enough.

E.g. here's my OpenBSD firewall, which syncs to a number of NTP servers on the net (including pool.ntp.org and time.apple.com):

   $ rdate -npv clock.isc.org
   Fri Dec 19 18:23:11 PST 2014
   rdate: adjust local clock by 0.012466 seconds
And here's an internal OS X desktop running Mountain Lion. It doesn't talk to any NTP servers on the Internet, only to my firewall system running OpenNTPD:

   $ ntpdate -qu clock.isc.org
   server 149.20.64.28, stratum 1, offset 0.011798, delay 0.05516
   19 Dec 18:24:43 ntpdate[2000]: adjust time server 149.20.64.28 offset 0.011798 sec

   $ ntpq -p
        remote           refid      st t when poll reach   delay   offset  jitter
   ==============================================================================
   *xxxxx.yyyyyyyy. 4.2.2.3          4 u  307  512  377    0.223    5.384   2.611
Being synced to within 12 milliseconds of a reliable stratum 1 NTP server is good enough for me. NB: I don't normally use clock.isc.org, there are plenty of stratum 2 and higher servers available for use.

Re: Multiple vulnerabilities released in NTP

#82

Post by grogers »

kstrauser wrote: post #52
bbulkow wrote: post #44

Earlier quoted context omitted.

Especially if your distributed database relies on clocks, as some do.

Eww. What does that? Vector clocks? Sure. UTC clocks? Not a chance in hell I'd ever trust them for a reconciliation protocol. I've spent way too much time around the internals of hypervisors, and seeing how various OSes (and versions of them) do and don't keep time well in virtualized environments gives me zero confidence. The fact that any two given cloud VMs agree on the time within 500ms is a testament to the shee…

AFAIK only spanner uses real time as a core primitive. They don't use ntp ;-)

Monotonic sequence numbers loosely based on real time are common, since you can correlate the sequence number back to an actual time to look at logs, etc. Time skew wouldn't break the protocol, just make it annoying to correlate after the fact.

And of course any leasing system uses bounded clock skew rate between hosts, but NOT bounded absolute skew.

Re: Multiple vulnerabilities released in NTP

#84

Post by lawnchair_larry »

SCdF wrote: post #66

Random non-trolling question by someone who is genuinely unfamiliar with the problem space: is it worthwhile rewriting these utilities in a language that avoids these sorts of problems? Is it because they're far more complicated than I realise and rewrites would create more problems that it solves? It is because until Rust is 1.0 there isn't a language that is suitable? Or am I missunderstanding the problem completel…

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.

Re: Multiple vulnerabilities released in NTP

#85

Post by imanaccount247 »

wglb wrote: post #78
imanaccount247 wrote: post #47

Earlier quoted context omitted.

>nor do they have all of the required algorithms required for proper timekeeping. I hear something like that a lot, yet all my systems run openntpd and all of them are keeping proper time without issue. What exactly is so not proper about it, and which algorithm exactly does it need to be "proper"?

From the openntpd.org site at http://www.openntpd.org/goals.html : Reach a reasonable accuracy. We are not after the last microseconds. Whereas NTP looks for maximum accuracy.

There's a big difference between "proper" and "more accurate than 99.999999999% of people care about" though. How many microseconds of accuracy do most people need? How many does openntpd provide and how many does the other ntpd provide? Claiming it isn't "proper" because in theory it may be 2 microseconds less accurate in some circumstances sounds like FUD.

Re: Multiple vulnerabilities released in NTP

#86

Post by kevinday »

cheeseprocedure wrote: post #23

Do these vulnerabilities impact a local ntpd instance responsible only for local timekeeping? (In other words, does a compromised machine in pool.ntp.org pose a threat?)

There are 6 bugs that were announced.

#1 Weak default key in config_auth()

If you're only doing local timekeeping, and not using authentication (you'd know if you were) this doesn't apply. Basically the automatically generated key used for authentication (if you didn't specify one) was only 31 bits long and easily guessable.

#2 non-cryptographic random number generator with weak seed used by ntp-keygen to generate symmetric keys

Same as the above. If you're not using keyed sessions with remote hosts, this doesn't apply to you. Even if you are, the worst you're losing here is that someone could potentially mess with your clock.

#3 Buffer overflow in crypto_recv()

If you are using crypto (i.e. your ntp.conf file contains a line starting with "crypto pw"), you are potentially remotely exploitable to remote code execution. You probably do not have that configuration line set unless you know you put it there.

#4 Buffer overflow in ctl_putdata()

From the sound of the post on ntp.org, this is the scary one. "A remote attacker can send a carefully crafted packet that can overflow a stack buffer and potentially allow malicious code to be executed with the privilege level of the ntpd process." This makes it sound like everyone is exploitable. However, Redhat says "the ctl_putdata() flaw, by default, can only be exploited via local attackers". This makes me believe if you have your ntp.conf locked down using the 'restrict' lines you might not be vulnerable.

#5 Buffer overflow in configure()

This is the same as #4, ntp.org's advisory is vague enough that it sounds like everyone is vulnerable. Redhat is saying "the configure() flaw requires additional authentication to exploit." I do not know what this means.

#6 receive(): missing return on error

From their description, it's technically possible (but they haven't done it) to get ntpd into a weird state that is unlikely to be exploitable.

TL;DR: You're possibly vulnerable to #4 and #5 on a stock configuration. Redhat says no, ntp.org's advisory is vague enough that I'm not sure.

Re: Multiple vulnerabilities released in NTP

#87

Post by uaygsfdbzf »

hannob wrote: post #27

The best solution is not to use ntp anyway. It's an unencrypted, unauthenticated protocol vulnerable to Man in the Middle attacks. There was a pretty neat attack presented at BH Europe circumventing HSTS with a MitM-attack on NTP. Better just replace it with tlsdate.

Your article about that:

https://blog.hboeck.de/archives/863-Dont-update-NTP-stop-usi...

Re: Multiple vulnerabilities released in NTP

#88

Post by dietrichepp »

zeeg wrote: post #67
SCdF wrote: post #66

Random non-trolling question by someone who is genuinely unfamiliar with the problem space: is it worthwhile rewriting these utilities in a language that avoids these sorts of problems? Is it because they're far more complicated than I realise and rewrites would create more problems that it solves? It is because until Rust is 1.0 there isn't a language that is suitable? Or am I missunderstanding the problem completel…

If you think introducing Rust (as an example) solves these kinds of problems you are sorely mistaken. Languages can make it easier for some things, but they're not a magical fix all. If it weren't this problem it would be something else, something that even "the great mythical Rust" can't prevent.

> A remote attacker can send a carefully crafted packet that can overflow a stack buffer and potentially allow malicious code to be executed with the privilege level of the ntpd process.

Rust, as an example, prevents exactly these kinds of problems.

Re: Multiple vulnerabilities released in NTP

#89

Post by moe »

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.

Here is the corresponding debate between the ntp guys and the OpenBSD guys (from 2004):

http://www.monkey.org/openbsd/archive/misc/0408/msg00562.htm...

The TLDR from the OpenBSD side of things:

    Hey, if ultra-precision time is an issue,
    go buy an atomic clock, I'm sure if your needs
    are that precise, you can probably afford it.

    openntpd is intended to be SMALL, SIMPLE and SECURE.
    Not HUGE, COMPLEX and "Hope for the Best".

Re: Multiple vulnerabilities released in NTP

#90

Post by _wmd »

mbq wrote: post #41
dfc wrote: post #35

Earlier quoted context omitted.

systemd-timesyncd is not much of an alternative. It is simply an sntp client, it does not serve time to other hosts nor can it use reference clocks.

Sure, but IMO enough many systems use NTP only in a sntp manner to mention it.

SNTP is only useful as an option of last resort, e.g. you have no embedded RTC, and no storage to track drift. In all other cases a full NTP client is always preferable, since drift and corrections can be applied without causing jumps to the system clock (triggering software bugs and misfired events), and drift statistics can be recorded -- which is inevitably required in almost all circumstances where you're using even high end PC motherboards that still rely on a $.15 crystal time reference
Post reply on HN