Blindly replacing ntpd with an alternative, that you have no experience with, for such a crucial service, does not seem like a good plan.
— ma.ttias.be (@mattiasgeniar) December 22, 2014
While I am at no point talking down the security risks and the impact of those
ntpd vulnerabilities, especially combined with the recent CVE-201-9322 that allows local user privilege escalation in recent RHEL/CentOS kernels, it is not worth completely abandoning a service overnight and blindly running to an alternative.
For instance, I saw a number of tweets with “suggestions” to fix these vulnerabilities with the following one-liner.
apt-get remove ntp && apt-get install tlsdate
This indeed removes
ntpd. And it indeed installs
tlsdate, which does not have CVE-2014-9295. Short-term, yes it’s a fix.
But you may no longer realise this, as most of it is automated/abstracted away behind a config management system of sorts, but
ntpd is a crucial part of your server. It’s as important as DNS resolving.
Should you really just replace this with a piece of software you don’t know? Are you monitoring
tlsdate? Did you configure
tlsdate properly? Do you know how to troubleshoot
tlsdate? Did you finetune the
tlsdate configs to your needs? Do you have years of experience with
tlsdate, as you do with
This doesn’t only apply to
ntpd, but the recent endeavours of the OpenSSL to LibreSSL fork as well. Why is it that as soon as a security vulnerability is found, everybody jumps ship to an alternative, without investing the resources to fix the problems in the first place? Do you really think the alternatives don’t have security loopholes?
Besides the shortsighted tweets and remarks, there are valid, well-supported arguments for migrating away from NTPD. You know, thoughts that don’t just occur overnight.
But forking projects and replacing crucial services without rational thinking only creates a greatly fragmented landscape in the open source community that nobody benefits from. And I’m aware that some projects are flawed by design, especially since they were designed over a decade ago. But even those projects can receive patches, bugfixes and refactored code to improve the quality.
The only time you should abandon a software project is after careful consideration of the alternatives, have experience with it in a test-environment and you know how to monitor, secure and debug said new software. Not the day after a vulnerability release as “a fix” to the problem. Abandoning a software stack is (almost) never the solution.