11 ms·
Multiple vulnerabilities released in NTP
- deleted 12y ago[deleted]
- deleted 12y ago[deleted]
- deleted 12y ago[deleted]
- hiphopyo 12y agoMight want to check out OpenBSD's OpenNTPD: http://www.openntpd.org/ http://www.openntpd.org/
- skuhn 12y agoThe 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.
- tedunangst 12y agoThere's little point to a non-portable release. They were made when ntpd was developing faster than OpenBSD, but it's not like OpenBSD stopped making releases in 2009.
- mbq 12y agoThere is also systemd-timesyncd and Chrony.
- TD-Linux 12y agoFedora (or GNOME 3?) uses Chrony by default due to better power management. I assume the same is true for most other distributions.
- vezzy-fnord 12y agosystemd-timesyncd implements SNTP, which is not the same.
- dfc 12y agosystemd-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.
- mbq 12y agoSure, but IMO enough many systems use NTP only in a sntp manner to mention it.
- _wmd 12y agoSNTP 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
- xorcist 12y agoSNTP is close to useless. Your time server could be off and you'd happily follow along.
- feld 12y agoI'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.
- imanaccount247 12y ago>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"?
- tedunangst 12y agoPeople who are into timekeeping are like, really, really into timekeeping. I've been skating by with improper timekeeping, too (whatever that means), but I only need to correlate web log entries and not hadron collisions.
- wglb 12y agoFrom the openntpd.org site at http://www.openntpd.org/goals.html http://www.openntpd.org/goals.html: Reach a reasonable accuracy. We are not after the last microseconds. Whereas NTP looks for maximum accuracy.
- imanaccount247 12y agoThere'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.
- noselasd 12y agoI 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.
- Sarkie 12y agohttp://webcache.googleusercontent.com/search?q=cache%3Asupport.ntp.org%2Fbin%2Fview%2FMain%2FSecurityNotice%23Buffer_overflow_in_ctl_putdata&oq=cache%3Asupport.ntp.org%2Fbin%2Fview%2FMain%2FSecurityNotice%23Buffer_overflow_in_ctl_putdata&aqs=chrome..69i57j69i58.798j0j4&sourceid=chrome&es_sm=0&ie=UTF-8 http://webcache.googleusercontent.com/search?q=cache%3Asuppo...
- PhantomGremlin 12y agoNTP 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 12y agoNTP'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.
- PhantomGremlin 12y agoTotally OT, but it would be amusing (to me at least) if Eric named his son Isaac.
- dfc 12y agoNTP's "author" --where author is defined as author of the original RFC (958), every subsequent RFC (1305, 5905, etc) and reference implementation-- is Prof. David Mills. Prof. Mills is one of the unsung heros of the internet.
- makomk 12y agontpd 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.
- voidz 12y agoThe 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.
- deleted 12y ago[deleted]
- yrro 12y agoIt 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 12y agoMix 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.
- adrr 12y agoBad timing for such a vulnerability with the holidays and everything. I don't have time for that.
- ossreality 12y agoYou don't have time to remote in and do an `apt-get update; apt-get upgrade`?
- breadtk 12y agoThe site appears to be non-responsive, here is a cached version of the page: https://webcache.googleusercontent.com/search?q=cache:jMcfipOGXXwJ:support.ntp.org/bin/view/Main/SecurityNotice+&cd=1&hl=en&ct=clnk&gl=us https://webcache.googleusercontent.com/search?q=cache:jMcfip...
- arca_vorago 12y agoThis 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 12y agohaving a host clock that is out of sync can be incredibly troublesome, especially if you have more than one system.
- bbulkow 12y agoEspecially if your distributed database relies on clocks, as some do.
- osivertsson 12y agoWhich sane distributed database relies on UTC or similar wall clock? When I did my distributed DB course way back when I was at uni it was all Lamport or vector clocks...
- kstrauser 12y agoEww. 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).
- grogers 12y agoAFAIK 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.
- ck2 12y agoA 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.
- tedunangst 12y agontpd is a, uh, rather large time sync program.
- jandrese 12y agoIndeed. 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.
- nknighthb 12y ago100,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.
- phkamp 12y agoActually, 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".
- nknighthb 12y agoI 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 server keeping an approximately accurate clock. If your response to me talks about just steering a clock, you are not responding to me.
- cheeseprocedure 12y agoDo 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?)
- Bino 12y agoThis 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?
- kevinday 12y agoThere 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.
- dfc 12y agoPHK 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 http://phk.freebsd.dk/time/20140926.html In the meantime Miroslav's chrony is a good alternative: http://chrony.tuxfamily.org/ 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 http://archive.ntp.org/ntp4/ntp-4.2/ntp-4.2.8.tar.gz
- deleted 12y ago[deleted]
- scrollaway 12y agosystemd also has a minimalistic ntp client. It does not implement the full ntp spec but is sufficient for most desktop and server systems.
- dfc 12y agoWhile the latter half of your comment is a matter of opinion/taste, the first half is categorically incorrect. systemd-timesync is not a minimalistic ntp client, it is a minimalistic sntp client. But do not take my word for it, the authors made this clear in the announcement: > A new "systemd-timesyncd" daemon has been added for synchronizing > the system clock across the network. It implements an SNTP client. I disagree that systemd-timesync is sufficient for most desktops and servers. We do not even need to go down the rabbit hole of discussing one's required stability/precision/accuracy to see a big problem with the "sufficiency" of systemd for most desktops/servers and the developers acknowledge it a couple sentences later in the announcement they "not bother with the full NTP complexity, focusing on querying time from one remote server and synchronizing the local clock to it." How do you detect falsetickers when you only have one sample? When they decided to ignore all the complexity they also chose to ignore clock drift. Maybe your dekstops/servers come with rubidium standards, but the rest of us have crappy crystals. I like that ntp/chrony decided to address clock drift...
- hannob 12y agoThe 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.
- NoMoreNicksLeft 12y agoI 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?
- Ricapar 12y agoThere 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.
- dvanduzer 12y agoThe 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.
- cbsmith 12y ago> 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).
- SEJeff 12y agoJust give it a few weeks and I'm sure the systemd developers will make their own "newer and better" ntpd.
- WestCoastJustin 12y agoYou're late to the party https://wiki.archlinux.org/index.php/systemd-timesyncd https://wiki.archlinux.org/index.php/systemd-timesyncd ;)
- AgentME 12y agoAll 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 12y agoThere 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.
- AgentME 12y ago>There are ways of bypassing stack canaries, depending on the specific application and environment. Bypassing a stack canary generally requires a separate memory disclosure vulnerability if I remember right. (Or an interesting local variable in the same function as the buffer like a function pointer, but I think compilers now are smart enough to try to arrange buffers to be the last thing on the stack before the canary.) It wouldn't be surprising if one existed, but I don't think any were publicly disclosed now. I guess what I'm asking is: 1) Are there any public exploits that get remote code execution against NTP on modern systems (Should we expect that the average MITM is popping shells with this already on most systems?), and 2) do all modern distributions (like say Debian) containing NTP have the standard default mitigations (DEP, stack canaries, etc) enabled on NTP, or why not?
- kator 12y agoDo these apply to ntpd in OSX?
- porsupah 12y agoI haven't verified the vulnerability locally, but as of OS X 10.10.1 (14B25), ntpd at least identifies itself as version 4.2.6, which is affected.
- tux 12y ago"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.
- SCdF 12y agoRandom 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.
- zeeg 12y agoIf 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.
- rian 12y agoAgree 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.
- dietrichepp 12y ago> 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.
- lawnchair_larry 12y agoNo, 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.
- PhantomGremlin 12y agoTheo de Raadt of OpenBSD weighs in on this issue: http://www.mail-archive.com/tech@openbsd.org/msg21729.html http://www.mail-archive.com/tech@openbsd.org/msg21729.html
- deleted 12y ago[deleted]
- xorcist 12y agoIt 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 12y agoI never knew how it worked, thanks for that very lucid explanation, I'm sure the devils in the implementation details but nevertheless.
- ztnewman 12y agoYou wouldn't consider a server at stratum 0 and NTP server?
- xorcist 12y agoDedicated ntp peers are often called servers. It's not strictly true in the client/server protocol architecture sense.
- jbarham 12y agoNaturally DJB recognized and fixed the security problems of NTP, way back in 1998: http://cr.yp.to/clockspeed.html http://cr.yp.to/clockspeed.html Plus ça change, plus c'est la même chose...