Multiple vulnerabilities released in NTP(support.ntp.org)
support.ntp.org
Multiple vulnerabilities released in NTP
http://support.ntp.org/bin/view/Main/SecurityNotice#Buffer_overflow_in_ctl_putdata
119 comments
[deleted]
systemd also has a minimalistic ntp client. It does not implement the full ntp spec but is sufficient for most desktop and server systems.
While 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.
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.
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.
I never knew how it worked, thanks for that very lucid explanation, I'm sure the devils in the implementation details but nevertheless.
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.
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.
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.
NTP'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.
Totally OT, but it would be amusing (to me at least) if Eric named his son Isaac.
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.
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.
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.
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.
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.
Well, there are still some good reasons to write things in C. For one it's standardized. Two it's ubiquitous.
I agree that projects should have a way to verify with 100% accuracy the memory safety of their code. One way to do that is to rewrite in another language.
Another way to do that is to use a static analyzer that lists out all unsafe operations in your codebase. Here's one http://goto.ucsd.edu/csolve/. Adds an extra build step / precommit-hook but IMO the cost/benefit is much better than rewriting your project. After all, we can't just rewrite our code every time a new safe language comes out.
I agree that projects should have a way to verify with 100% accuracy the memory safety of their code. One way to do that is to rewrite in another language.
Another way to do that is to use a static analyzer that lists out all unsafe operations in your codebase. Here's one http://goto.ucsd.edu/csolve/. Adds an extra build step / precommit-hook but IMO the cost/benefit is much better than rewriting your project. After all, we can't just rewrite our code every time a new safe language comes out.
You don't seem to understand this problem space.
[deleted]
Ntpd should be replaced with something different, not rewritten. There is no reason to rewrite it. But I agree, there is no good reason to write such things in C anymore.
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.
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.
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.
Rust, as an example, prevents exactly these kinds of problems.
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.
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.
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.
#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.
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?
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?
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.
I wonder because this would also affect what arbitrary code could be run as the ntp user.
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+epMix 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.
Generally, at any time, it's safer to assume there's at least one active local root exploit in any system.
[deleted]
Might want to check out OpenBSD's OpenNTPD:
http://www.openntpd.org/
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):
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
$ 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
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:
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".late edit: Might make sense to say "precise" instead of "proper"
>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 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"?
People 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.
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.
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.
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.
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.
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.
Also, the last release of non-portable openntpd is from 2009.
There'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.
There is also systemd-timesyncd and Chrony.
Fedora (or GNOME 3?) uses Chrony by default due to better power management. I assume the same is true for most other distributions.
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
SNTP is close to useless. Your time server could be off and you'd happily follow along.
systemd-timesyncd implements SNTP, which is not the same.
The site appears to be non-responsive, here is a cached version of the page: https://webcache.googleusercontent.com/search?q=cache:jMcfip...
Theo de Raadt of OpenBSD weighs in on this issue:
http://www.mail-archive.com/[email protected]/msg21729.html
http://www.mail-archive.com/[email protected]/msg21729.html
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.
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).
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).
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.
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.
Which 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...
When I did my distributed DB course way back when I was at uni it was all Lamport or vector clocks...
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.
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.
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.
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.
Also, in many cases applications will be distributed or have Makefiles without enabling stack canaries or sometimes even DEP and ASLR.
>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?
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?
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.
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 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.
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.
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't require millisecond level time sync...)
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...
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).
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.
Bitcoin relies on more than NTP so it's not a huge vulnerability, but NTP's vulnerability is a headache to many security developers.
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...
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...
Your article about that:
https://blog.hboeck.de/archives/863-Dont-update-NTP-stop-usi...
https://blog.hboeck.de/archives/863-Dont-update-NTP-stop-usi...
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?
Or can you circumvent certificate revocations this way?
You could circumvent certificate revocations by replaying expired OCSP Staple responses that say a certificate is not revoked.
You could also cause expired certificates to be accepted, which limits the utility of short-lived certs as a means of protecting against key compromise.
And as hannob said, you can circumvent HSTS by setting the time in the future, causing all HSTS entries to be expired.
You could also cause expired certificates to be accepted, which limits the utility of short-lived certs as a means of protecting against key compromise.
And as hannob said, you can circumvent HSTS by setting the time in the future, causing all HSTS entries to be expired.
For that to work you need to compromise _all_ the NTP servers those servers sync to for an extended period of time (years). It's simply not a realistic attack.
NTP does not sync time. NTP measures time drift across groups of servers, and sprinkles in known time. I'm not saying authentication is useless, you should turn it on for your known time sources, but it's not so simple as you make it out to be.
Unless you use SNTP on your servers. Don't do that. Ever.
NTP does not sync time. NTP measures time drift across groups of servers, and sprinkles in known time. I'm not saying authentication is useless, you should turn it on for your known time sources, but it's not so simple as you make it out to be.
Unless you use SNTP on your servers. Don't do that. Ever.
In practice, there are systems that use SNTP or regular NTP with periodic calls to ntpdate. Ubuntu does the latter, by default, and is thus susceptible to the attacks I described,
That's a bug with Ubuntu. That mode of operation is for devices without persistent real time clocks or personal laptops where time isn't that important. If you sync your time at reboots you will screw up ntpd's clock drift calculations.
Pretty persistent attacker. It should take something like 100 days to push the clock off by one day.
This kind of attack should be difficult, because NTP clients should be configured to ignore large offsets. See the (dangerous) -g option in the ntpd manpage, for example.
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.
Being able to control he time could theoretically let you control any PRNGs that rely on it.
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.
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.
Maybe I wasn't clear, but I was thinking one would manipulate the delta specifically to cause the machine to adjust its clock.
It's more than that. There is tons of logic in crypto protocols around timeouts, and of course services themselves often have bugs around the handling of time (there's a great list of assumptions developers make about time that are fatal and create all kinds of security problems).
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).
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).
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.
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.
If you are really worried, use layer 3 or layer 2 security (say with IPSec) to secure NTP communications.
Yes, there is a bit of a bootstrapping problem, but you can address that with a bootstrapped handshake that sets a clock baseline.
Alternatively, you could just hardwire a radio receiver (like say... a GPS receiver).
Yes, there is a bit of a bootstrapping problem, but you can address that with a bootstrapped handshake that sets a clock baseline.
Alternatively, you could just hardwire a radio receiver (like say... a GPS receiver).
Accurate time is pretty important to computers. An attacker that can skew time can bypass HSTS, expire cookies, etc.
Actually, NTP has (limited) support for authentication and encryption. I would agree it's pretty lame though.
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...
Plus ça change, plus c'est la même chose...
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.
Geez, in a time sync program? Nothing is safe anymore.
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.
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.
Actually, 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".
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".
I 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.
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.
Apologies for being a bit terse, but I've got stuff to do, including buying X-mas presents for my family :-)
I've already written about most of this in my little "time-blog" related to this project: http://phk.freebsd.dk/time/index.html
Feel free to ask any questions not already answered there.
Right now ntimed is less than 4KLOC and while it isn't complete yet, it does contain precision timekeeping, a data collector to record simulation input, a simulator to chew on those tracefiles and the real-time clock-steering code.
It really isn't rocket size.
OpenBSD's NTP implementation is similar size, but they sort of threw their hands op on smart clock-steering, opting instead for "KISS" from a security point of view.
The main reason I didn't start from OpenBSD's NTP implementation is that it is not aimed at being part of a larger family of time-keeping programs, like I intend to deliver, so it wouldn't save me any time in the end.
(I'll be proud if OpenBSD adopts my ntimed, but I'll fully understand and accept if they do not.)
Adding support for being a NTP server is mostly a matter of writing code to defend against packet storms (See: http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#D-L...)
Adding refclocks should never happen in the "main" process, but rather they should be separate processes, suitably sandboxed and interfaced via a good simple API. (I have radical plans for this, which will allow refclocks to be implemented in PL/1, REXX or INTERCAL if that's how you roll :-)
But right here, right now, my focus is to get the vast majority of all machines away from running NTPD, purely as a matter of security and robustness, while improving their timekeeping at the same time.
If ntimed-client ever grows above 10KLOC, I've failed that goal.
First preview release of the source code will happen this weekend.
I've already written about most of this in my little "time-blog" related to this project: http://phk.freebsd.dk/time/index.html
Feel free to ask any questions not already answered there.
Right now ntimed is less than 4KLOC and while it isn't complete yet, it does contain precision timekeeping, a data collector to record simulation input, a simulator to chew on those tracefiles and the real-time clock-steering code.
It really isn't rocket size.
OpenBSD's NTP implementation is similar size, but they sort of threw their hands op on smart clock-steering, opting instead for "KISS" from a security point of view.
The main reason I didn't start from OpenBSD's NTP implementation is that it is not aimed at being part of a larger family of time-keeping programs, like I intend to deliver, so it wouldn't save me any time in the end.
(I'll be proud if OpenBSD adopts my ntimed, but I'll fully understand and accept if they do not.)
Adding support for being a NTP server is mostly a matter of writing code to defend against packet storms (See: http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#D-L...)
Adding refclocks should never happen in the "main" process, but rather they should be separate processes, suitably sandboxed and interfaced via a good simple API. (I have radical plans for this, which will allow refclocks to be implemented in PL/1, REXX or INTERCAL if that's how you roll :-)
But right here, right now, my focus is to get the vast majority of all machines away from running NTPD, purely as a matter of security and robustness, while improving their timekeeping at the same time.
If ntimed-client ever grows above 10KLOC, I've failed that goal.
First preview release of the source code will happen this weekend.
You're defending a lot of stuff I didn't attack. Almost everything you're doing sounds good to me, and I have no idea why you would think otherwise.
The only point I made was that 100,000 lines is not staggering for all of the functionality ntpd encompasses, which goes way beyond just "query and steer".
I didn't say a typical NTP client should be 100,000 lines. 10,000 lines sounds far, far too large to me, in fact, for the 80-90% case.
The only point I made was that 100,000 lines is not staggering for all of the functionality ntpd encompasses, which goes way beyond just "query and steer".
I didn't say a typical NTP client should be 100,000 lines. 10,000 lines sounds far, far too large to me, in fact, for the 80-90% case.
I think phkamp's words relevant for you are:
> aimed at being part of a larger family of time-keeping programs, like I intend to deliver
I am guessing that ntimed-client is intended for the 99.99% use case for most offices, homes and internet providers (which is client-server, not peer-to-peer), and that another program in the family will provide for your use case, which sounds very advanced to me.
> aimed at being part of a larger family of time-keeping programs, like I intend to deliver
I am guessing that ntimed-client is intended for the 99.99% use case for most offices, homes and internet providers (which is client-server, not peer-to-peer), and that another program in the family will provide for your use case, which sounds very advanced to me.
First, all functionality included, NTPD is presently 363.000 lines of .c and .h files.
Second, the 100.000 is my guesstimate of what is necessary for "core functionality" and I think that is still a pretty staggering size for what that "core functionality" is.
There is a lot of ancient infrastructure which complicates otherwise very simple tasks, some design-choices, perfectly valid in 1980 should have been revisited no later than 2000, far too much duplicated functionality, because people didn't know or couldn't get the other copy working etc.
My initial plan was to do a serious rebuild of the existing code, in deference to Prof. Dave Mills and NTPDs long legacy (probably one the longest running open source projects!), but in the end I had to admit that such a strategy would be inefficient on any relevant metric.
I think I could write a bare-bone NTP client in well less than 1000 lines, but it wouldn't be very user-friendly, net-friendly or clock-friendly.
Usability in particular soaks up space, but we're not in 1980 any more, so there is no excuse for stuff like this any more:
... and that will still be less than 3% of the current NTPD.
Second, the 100.000 is my guesstimate of what is necessary for "core functionality" and I think that is still a pretty staggering size for what that "core functionality" is.
There is a lot of ancient infrastructure which complicates otherwise very simple tasks, some design-choices, perfectly valid in 1980 should have been revisited no later than 2000, far too much duplicated functionality, because people didn't know or couldn't get the other copy working etc.
My initial plan was to do a serious rebuild of the existing code, in deference to Prof. Dave Mills and NTPDs long legacy (probably one the longest running open source projects!), but in the end I had to admit that such a strategy would be inefficient on any relevant metric.
I think I could write a bare-bone NTP client in well less than 1000 lines, but it wouldn't be very user-friendly, net-friendly or clock-friendly.
Usability in particular soaks up space, but we're not in 1980 any more, so there is no excuse for stuff like this any more:
#define DEFPROPDELAY 0x00624dd3 /* 0.0015 seconds, 1.5 ms */
critter phk> ./ntimed-client -p pll_std_capture_time
Parameter:
pll_std_capture_time
Minimum:
2.000e+01
Maximum:
1.000e+06
Default:
3.000e+02
Description:
Capture time before stiffning PLL.
After this many seconds, the PLL will start to stiffen the P
and I terms to gain noise immunity. Decreasing risks that
initial frequency capture is not finished, which will increase
the offset-excursion. Increasing just delays this stiffning.
Failure: Stopping after parameter query.
... and that will still be less than 3% of the current NTPD.
I really have no interest in this. You're being incredibly defensive and looking for reasons to argue with someone you don't fundamentally disagree with about trivial crap. For someone who professes to be so busy, that's very strange.
I would guess that PHK, being PHK, is just being thorough rather than defensive. After all, if you can avoid a lot of back and forth, you're saving everybody time. Of all people here, he's definitely one of the ones worth giving the benefit of the doubt.
Observing this discussion, I read him as being explanatory in great detail. Which I am finding interesting.
And he certainly know more about the ntpd family than I.
And he certainly know more about the ntpd family than I.
"I would have written a shorter letter, but I did not have the time." -- Blaise Pascal
Most of code is hardware support for a multitude of GPS receivers and other clocks.
[deleted](1)
"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.
[deleted]
Bad timing for such a vulnerability with the holidays and everything. I don't have time for that.
Just give it a few weeks and I'm sure the systemd developers will make their own "newer and better" ntpd.
You're late to the party https://wiki.archlinux.org/index.php/systemd-timesyncd ;)
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