Multiple vulnerabilities released in NTP

[dfc]

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/ntp-4.2.8.tar.gz

[scrollaway]

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

[Sarkie]

http://webcache.googleusercontent.com/search?q=cache%3Asuppo...

[xorcist]

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 (which is what the stratum value is, a measure of distance to known good time) is then sprinkled in from several sources to drift the time in the direction of true time.

Exactly as you should have a number of secondary DNS servers in different AS, you should use several different time sources from different organizations. If you are bigger than a closet shop, you might as well put your own GPS receiver in there too when sparkfun sells them for $40, and enable authentication on it.

[whistlerbrk]

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

[ztnewman]

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

[PhantomGremlin]

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

Edit: forgot to mention that OpenNTPD does privilege separation (don't know if reference implementation has added that yet). Which means that "executed with the privilege level of the ntpd process" isn't nearly as scary as when the process is running as root.

[VonGuard]

NTP's author, Eric Fair, is actually the son of the founder of Fair-Issac. Very smart cat, but this was all written so, so long ago it was bound to be exploitable sooner or later.

[makomk]

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.

[SCdF]

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

My reasoning comes from the vast majority of problems I notice being from the edge cases in managing memory, and so if I understand correctly there is a whole suite of languages that mostly remove these problems.

[lawnchair_larry]

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.

[zzzcpan]

Nowadays it is possible to catch these kinds of errors ahead of time and at runtime with some help from static analyzers and other special tools, like AddressSanitizer. This report itself is likely to be the result of such work. So, rewrite is not worthwhile if your reasoning is to prevent edge cases in managing memory.

[zeeg]

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.

[cheeseprocedure]

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

[kevinday]

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.

[Bino]

This should be stated more clearly. Should we all panic?

Does it affect any ntpd asking for time?

Does it affect a ntpd asking a compromised server for time?

Does it only affect ntpds answering to time requests?

[voidz]

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.

[yrro]

It appears to use capabilities:

  $ ps u 561
  USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
  ntp        561  0.0  0.0   5856   780 ?        Ss   Jul14  22:37 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 103:107

  $ /sbin/getpcaps 561
  Capabilities for `561': = cap_net_bind_service,cap_sys_time+ep

[wickberg]

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.

[hiphopyo]

Might want to check out OpenBSD's OpenNTPD:

http://www.openntpd.org/

[feld]

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.

[skuhn]

The portable version (for Linux and other OSes) is unmaintained and the last release is from 2006. I don't use it on that basis alone.

Also, the last release of non-portable openntpd is from 2009.

[mbq]

There is also systemd-timesyncd and Chrony.

[breadtk]

The site appears to be non-responsive, here is a cached version of the page: https://webcache.googleusercontent.com/search?q=cache:jMcfip...

[PhantomGremlin]

Theo de Raadt of OpenBSD weighs in on this issue:

http://www.mail-archive.com/[email protected]/msg21729.html

[arca_vorago]

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.

[kbar13]

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

[cbsmith]

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.

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

[rudolf0]

There are ways of bypassing stack canaries, depending on the specific application and environment. No exploitation mitigation is ever fool-proof.

Also, in many cases applications will be distributed or have Makefiles without enabling stack canaries or sometimes even DEP and ASLR.

[hannob]

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.

[dfc]

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 PTP to acquire and synch to UTC.

Why would anyone need encrypted time synch? I do not understand the privacy implications, UTC is not a secret.

[1]: For example: http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm or https://www.nrc-cnrc.gc.ca/eng/solutions/advisory/calibratio...

[2]: My sure gps puck cost $40. It works with the antenna sitting on the window ledge inside my house.

[uaygsfdbzf]

Your article about that:

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

[NoMoreNicksLeft]

I don't understand what attacks are possible... making an enemy late for work when his alarm goes off several hours late?

Or can you circumvent certificate revocations this way?

[cbsmith]

Actually, NTP has (limited) support for authentication and encryption. I would agree it's pretty lame though.

[jbarham]

Naturally DJB recognized and fixed the security problems of NTP, way back in 1998: http://cr.yp.to/clockspeed.html

Plus ça change, plus c'est la même chose...

[ck2]

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.

Geez, in a time sync program? Nothing is safe anymore.

[tux]

"The connection was reset" something weird going on. Lots of HN articles is been removed by some one. Many sites I visited today, is just down.

[kator]

Do these apply to ntpd in OSX?

[adrr]

Bad timing for such a vulnerability with the holidays and everything. I don't have time for that.