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

51–60 of 120 posts

Re: Multiple vulnerabilities released in NTP

#51

Post by makomk »

PhantomGremlin wrote: post #5

NTP is one of those old school Internet protocols that was developed in "a more civilized age". The reference implementation "growed like Topsy" in an academic setting. So it's not surprising that it has serious vulnerabilities. Many years ago OpenBSD threw up their hands and just decided to roll their own, named OpenNTPD. It's not nearly as full featured as the reference implementation, but it works fine for most pe…

ntpd shouldn't be running as root on modern Linux systems anyway. It supports using capabilities to drop all privileges aside from the ability to set the system time, and I think most distros have it configured that way.

Re: Multiple vulnerabilities released in NTP

#52

Post by kstrauser »

bbulkow wrote: post #44
kbar13 wrote: post #20

Earlier quoted context omitted.

having a host clock that is out of sync can be incredibly troublesome, especially if you have more than one system.

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 sheer bullheaded determination of their administrators.

Simply, you cannot trust timestamps between two machines to determine ordering. If you do, you will have a bad time sooner or later (so to speak).

Re: Multiple vulnerabilities released in NTP

#53

Post by Taek »

dfc wrote: post #32
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.

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…

Encrypted might not be necessary but you want to be sure your computer is getting the right time. An out of sync Bitcoin miner for example will only produce invalid blocks. Tor I believe also relies on an accurate clock.

Bitcoin relies on more than NTP so it's not a huge vulnerability, but NTP's vulnerability is a headache to many security developers.

Re: Multiple vulnerabilities released in NTP

#54

Post by FireBeyond »

dfc wrote: post #42
FireBeyond wrote: post #36

Earlier quoted context omitted.

You need encrypted time sync when you don't have a local trusted source, and to reduce your susceptibility to to pseudo MITM attacks (though, having just said that, you're right - UTC isn't a secret, so an attacker could just use that. However, and I'm not sure the answer, the key may be in how much information is leaked to the NTP server on current clock drift state. That being said, I'm fairly sure Kerberos etc don…

You are confusing authentication and encryption. Authenticated time protects against MITM attacks. You can obtain authenticated time synch from many national labs, such as NIST[1] or CRC[2]. I do not understand the need for confidentiality. [1]: http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm [2]: https://www.nrc-cnrc.gc.ca/eng/solutions/advisory/calibratio...

Well, my thought was that you might be able to determine local clock drift by snooping. But as then mentioned, that's of near zero use, I suspect (as anything that uses time sync for authentication or otherwise is not likely to be that tightly bound to accuracy).

Re: Multiple vulnerabilities released in NTP

#55

Post by wickberg »

voidz wrote: post #7

The ntpd daemon does not run as root. So, how is it able to change the time of the system? Does it use setuid, or caps, or something else? I wonder because this would also affect what arbitrary code could be run as the ntp user.

Mix in the just-announced CVE-2014-9322, among others, and you have a fairly obvious path to root.

Generally, at any time, it's safer to assume there's at least one active local root exploit in any system.

Re: Multiple vulnerabilities released in NTP

#56

Post by nknighthb »

jandrese wrote: post #46
tedunangst wrote: post #19

Earlier quoted context omitted.

ntpd is a, uh, rather large time sync program.

Indeed. PHK noted that it's on the order of 100,000 lines of code. That's a staggering amount for something that queries a remote server and steers your clock.

100,000 lines of C is certainly unnecessary for the most common usage of ntpd, but it is far from staggering considering ntpd's full scope as a portable client, server, and peer-to-peer node attempting high precision synchronization on heterogeneous hardware across the globe.

It doesn't just "query a remote server and steer your clock", and "steer your clock" is a lot more complicated than it sounds when you're trying to achieve such precision.

Re: Multiple vulnerabilities released in NTP

#57

Post by AgentME »

All of the buffer overflows are on the stack, right? Shouldn't the default stack protector that most compilers today enable should stop that from being exploitable for remote code execution?

I'm just trying to estimate the likelihood that anyone was hacked through this vulnerability. Even with stack protection the vulnerability could be used to crash ntp, so upgrading is a very good idea still.

Post reply on HN