Slashdot Mirror
OpenBSD Releases a Portable Version of OpenNTPD
Noryungi (70322) writes Theo De Raadt roundly criticized NTP due to its recent security advisories, and pointed out that OpenBSD OpenNTPD was not vulnerable. However, it also had not been made portable to other OS in a long time. Brent Cook, also known for his work on the portable version of LibreSSL (OpenBSD cleanup and refactoring of OpenSSL) decided to take the matter in his own hands and released a new portable version of OpenNTPD. Everyone rejoice, compile and report issues!
ntp is surprisingly complex to deal with a surprisingly complex thing. If tlsdate was a decent enough utility, then we'd still be using the time protocol of rdate as the go-to time sync strategy. Precision and quality is much lower.
There's also a couple of tricky things. One is that it could be dropped in TLS 1.3. Another is that it doesn't play with the concept of TLS certificate expiry.
Basically, this is a potentially handy utility to take the place of rdate, not something that begins to touch ntp.
XML is like violence. If it doesn't solve the problem, use more.
[Full Disclosure: I have been a member of the NTP Hackers team for ~15 years, so you could claim that I'm partly to blame for the recent security problems even if I have not personally worked on the crypto or monitoring code.]
NTPD is definitely more complicated that what you need for a leaf (client-only) machine, like all the server functions and the code that support locally attached reference clocks, this is the main reason PHK is working on a dedicated NTP client.
We have known for many years that the monitoring functions, in particular the "mode 6" UDP packets were a potential DDoS amplification vector, which is why we replaced them.
For the crypto stuff we did what pretty much every other project did, i.e. we imported the functions we needed from openssl, and like pretty much every other project we messed up a few buffer handling issues.
The important point here is that anyone running a public server with a recommended configuration (no crypto, no remote monitoring) would not have had any security problems, even if they insisted on using 10+ year old versions!
With any version from withing the last 3-5 years you would also have been secure against the DDoS vector even if you did allow remote status monitoring.
How many system-level sw packages are you using where this would have bee true?
Terje
PS. OpenNTP should properly be called OpenSNTP, since it implements the Simple NTP subset instead of the full NTP protocol stack which includes system clock time/frequency tuning.
"almost all programming can be viewed as an exercise in caching"
imo, when you go for that last nanosecond of accuracy as the highest priority
That's kind of the whole point of a timeserver. If you're just running a typical client that doesn't need precision there are a multitude of SNTP implementations that you can use, including the one built into Windows. If you're running something that demands precision or wish to share your time with others (random plug: NTP Pool) you're going to need a little bit more accuracy than that.
and lower the priority of writing secure software to the point where it is no longer a priority, then you have ntp.
ntpd has been around since the 80s. Contrast it against other system daemons that have been around that long (sendmail) and you'll see that it has a solid security record. The recent "exploits" only impacted a small subset of servers that were using the cryptographic functionality of ntpd, which is primarily used for remote management and peering relationships and was a non-issue for the lion's share of configurations. Configurations to work around the issues were released immediately and a patch to solve them entirely was available within days. What more do you want? This was all discussed on the NTP Pool mailing lists and the consensus was "meh." I'm not aware of any NTP server that has been compromised because of these exploits.
The biggest issue that's hit ntpd in the last year was the ease with which you could use the 'monlist' command for amplification attacks. This too was easily solved with a configuration change and in any event did not compromise the integrity of the servers running ntpd. It's symbolic of a larger problem that has hit other protocols (DNS) and which will never go entirely away until network operators get off their lazy asses and implement the recommendations of BCP38.
I want peace on earth and goodwill toward man.
We are the United States Government! We don't do that sort of thing.