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
This tweet referred to the blind replacing of the ntpd daemon by alternatives, such as tlsdate and OpenNTPD, as a result of the vulnerabilities found in ntpd.
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 ntpd?
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.