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

71–80 of 120 posts

Re: Multiple vulnerabilities released in NTP

#71

Post by cbsmith »

dvanduzer wrote: post #37
Ricapar wrote: post #29

Earlier quoted context omitted.

There is still a lot of crypto out there that works off of using the current timestamp as a seed. Being able to control he time could theoretically let you control any PRNGs that rely on it.

The much bigger issue is with hardware that doesn't have a local clock/battery. Critical initialization code should probably compare uptime with current epoch time if it needs a random seed for a long-use token.

> 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 perhaps try to add entropy from a clock, but you'd want another source of entropy. Generally crypto code needs network clocks for other things (think of Kerberos ticket expiration).

Re: Multiple vulnerabilities released in NTP

#72

Post by rian »

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.

Agree that Rust is not a magical fix-all solution. Rust ensures memory safety and prevents data-races but there are still a whole universe of programming-error-induced vulnerabilities that Rust will happily compile and run.

Don't get me wrong, using a more restrictive language will help but it's not a fully-baked solution. We need more third-party tools to help us automatically verify the correctness of our programs. It shouldn't stop at compilers.

Re: Multiple vulnerabilities released in NTP

#73

Post by cbsmith »

arca_vorago wrote: post #17

This is interesting timing, I was just in the freenode #linux channel yesterday asking about security issues with NTP. I got told it was a non-issue and that I was "tilting at windmills". I have been using chronyd in Alpine linux to good effect so far, but have really been wondering how bad it would be if I just turned it all off.

Synchronized network clocks are pretty important for a lot of secure distributed computing. If you aren't doing that, maybe you can get away without it.

Re: Multiple vulnerabilities released in NTP

#74

Post by dfc »

hannob wrote: post #45
dfc wrote: post #32

Earlier quoted context omitted.

ntp network traffic can be authenticated with symetric keys or autokey currently, and with NTS in the future. Many national labs support authenticated time for free and even more provide authenticated ntp for a fee.[1] Moreover if you care about time you can use a cheap GPS+PPS[2] as a reference or splurge and get a CDMA card. Your "replace it with tlsdate" solution makes little sense; at some point you need NTP or P…

ntp authentication is broken: http://zero-entropy.de/autokey_analysis.pdf and it was the same guy who found the new vulnerabilities :-)

In order for the attack to succeed Eve needs to be able to MITM every configured ntp server association and do so before the daemon starts up.

FYI Stephen Röttger is also the same guy who is a co-author of the two IETF proposals for the successor to autokey; Network Time Security[1] and Crypto Message Syntax for NTS[2].

[1]: https://tools.ietf.org/html/draft-ietf-ntp-network-time-secu...

[2]: https://tools.ietf.org/html/draft-ietf-ntp-cms-for-nts-messa...

Re: Multiple vulnerabilities released in NTP

#75

Post by protomyth »

hannob wrote: post #43
tedunangst wrote: post #38

Earlier quoted context omitted.

Pretty persistent attacker. It should take something like 100 days to push the clock off by one day.

Ubuntu accepts arbitrary time jumps, the attack was presented live at BH with an Ubuntu System.

so you can see Ubuntu so it is 03:14 UTC on 19 January 2038? That might be bad, how big is their time_t?

Re: Multiple vulnerabilities released in NTP

#76

Post by dvanduzer »

cbsmith wrote: post #71
dvanduzer wrote: post #37

Earlier quoted context omitted.

The much bigger issue is with hardware that doesn't have a local clock/battery. Critical initialization code should probably compare uptime with current epoch time if it needs a random seed for a long-use token.

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

Re: Multiple vulnerabilities released in NTP

#77

Post by dvanduzer »

cbsmith wrote: post #70
tedunangst wrote: post #39

Earlier quoted context omitted.

I don't think I need to control your clock when I can just look at my watch and know what your clock says. Why do things the hard way?

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.

Re: Multiple vulnerabilities released in NTP

#78

Post by wglb »

imanaccount247 wrote: post #47
feld wrote: post #15

Earlier quoted context omitted.

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.

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

Re: Multiple vulnerabilities released in NTP

#80

Post by noselasd »

imanaccount247 wrote: post #47
feld wrote: post #15

Earlier quoted context omitted.

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.

>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"?

I do not know if this is an issue with other ntp daemons today, but I've been bitten by some of them in the distant past - they might keep the time fine, but it really sucks if they sometimes jump the clock instead of properly slewing it.

Having to try to debug intricate problems and not knowing if you can trust timestamps on the logs for the actual order of events can drive you nuts.

Post reply on HN