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!
I'm led to believe that the reason we're using ntpd and not any of the other is that, although they are fine for getting your home machine to approximately the right second, they are damn-near useless for anything that you want real time-keeping for.
So if you want to interact with stratum-1's or be a stratum-2, then you'll be using ntpd. And, en-masse, NTP is not something as simple as just clock-skewing. That throws lots of things out of kilter. Granted, you may think you don't care, but these things can come back to bite you if you make a hasty decision now.
When someone like the NTP pool project (that I run a couple of serverse on) come to me and tell me that ntpd isn't secure enough, and that OpenNTP is good enough , then maybe I'll go over to them. Fact is, I haven't heard anything along those lines.
There's a lot of maths behind getting your clocks in sync quickly without going backwards in time, or slowing to a crawl, or messing up timestamps a lot. It's not as simple as "let's just drag the users clock closer to the reference one constantly". ntpd does a LOT that other NTP servers don't, and a lot of that is important for anything that you want to rely on a timeserver for.
Sorry, but this is just blatant "Look at us, we run an NTP project that's secure" when actually it does less than 10% of what ntpd does. And to make it do what ntpd does, presumably will take years of work to secure.
There are various "rewrite" projects at the moment, but all known holes with ntpd are closed. Until there's a compelling reason to move, don't. And by the time there is, you'll find properly-written, full-featured NTP projects being offered.
Nobody's talking about sub-millisecond accuracy here either. We're just talking not cocking up the one thing you plug in an NTP server to get right - the time.
Like chrony.
I wouldn't recommend openntpd because it isn't an implementation of ntp
Hey, speak for yourself! I wrote a secure "hello world" once....
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
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.
Hey, speak for yourself! I wrote a secure "hello world" once....
Did you checked and managed the return value?
Lol >_>
If you're seriously proposing tlsdate as an ntp replacement you haven't understood what ntp does (and most probably you haven't understood time keeping in a machine either).
.
On my internal network, I used ntp as the ntp server for my house. I put "listen interface" in the ntp.conf file, and instructed it to listen only on the 10.1.1.1 interface. yet netstat showed that ntp was still listening on *:123. It's sloppy design and sloppy coding.
When I see things like that right in front of me, I am left to wonder about the quality of the code that I cannot see.
I wrote a super secure interactive hello world once, so the user could see "hello world" in any language of their choice:
int main (int argc, char **argv) {
char hello[256];
gets(hello);
printf("%s\n", hello);
return 0;
}
Works best when run with root permissions. :)
I want peace on earth and goodwill toward man.
We are the United States Government! We don't do that sort of thing.
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.
Please enlighten us.
It sets your local server time immediately if you use -s. Otherwise, it slowly drifts your local clock to the real time, which could take days if it is far off. I always use ntpd -s on boot for systems with no RTC. Or ntpd -s when my clock is way off. The drift feature is designed to keep software from freaking out due to sudden time changes.
On my internal network, I used ntp as the ntp server for my house. I put "listen interface" in the ntp.conf file, and instructed it to listen only on the 10.1.1.1 interface. yet netstat showed that ntp was still listening on *:123. It's sloppy design and sloppy coding.
interface ignore wildcard
Took a look. Found a bug in 2 seconds. Theo is really quite full of himself.
For the bug take a look at the "host" function in parse.y. Who can spot what the function returns and what it's being tested against.
Did you write a secure compiler for it, too?
That's cool. But you're getting served SNTP, not NTP as you might be forgiven to infer from the name OpenNTP.
There is a difference, yes. It may well be that to your 10k devices the difference is moot. But to some it does matter quite a lot, and if they let themselves be misled by the name they'll get bitten. So, your success story does not universally scale. In picking the name like they did, the openbsd people did the world a disservice.
ntpdate on a cron is a nice alternative to running the full ntp server, if you just want accurate time.. I've had to set this up on a network wherein each server running ntp server created too much drift between them (all servers needed to be within 100 ms of eachother). Easiest solution is all servers run ntpdate every minute against a single host within the network. Drifting averaged about 20ms with that simple solution.
Then I guess he's not working on OpenBSD.
http://www.openbsd.org/errata5...
While this is funny, it is also very insightful. Writing secure software is possible. It requires significant talent, experience, skill, knowledge and time. Not many people can do it and those that can will usually not find an employer that pays for it.
That said, there are principles and approaches on all levels (architecture, design and implementation) that help. There are testing approaches that help, from fuzzing to things like Fortify. There are things like design-by-contract. There are non-technical measures such as peer-review to help, but expect the review to be about as much effort and take about as much skill as the implementation work. In an industry that has an insane and self-destructive desire for ever cheaper programmers, secure software will not and cannot be created. People that can create secure software are at least on the level of senior engineers and need to be treated and compensated in that fashion and need to have a realistic technical career path. The current conditions are not like that at all, with rare exceptions. We have forgotten that the "chief engineer" is critical to make complex technology work and keep it working. Instead, many CTOs are not even proper engineers or never really worked as such, but are the of the same, clueless "bean-counter" pedigree that in the end ruins everything.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
DragonFly has had its own ntp-only client for years, dntpd. Not sure why this is suddenly becoming a topic now.
In terms of portability, every operating system has different sysctls or system calls for manipulating the clock. There is no single standard for setting the frequency drift correction, step, or slide operations to correct the time. And part of the problem is that most of these APIs are deficient in one way or another and make it difficult for the ntp client to run the corrections without generating feedback which messes up further corrections.
Beyond that, the code is fairly straight-forward.
-Matt
I use NTPD's ntpdate on boot to sync my clock and then leave it running while the system is up to manage drift.
On the LANs I administer, I usually configure at least one box as an NTP server for the network so I don't have everyone and their dog sending unnecessary UDP packets out to the Interwebs.
- Michael T. Babcock (Yes, I blog)
Just a look at their ntpd.conf man page makes me want to switch to OpenNTPD yesterday.
Old ntpd man pages suck so hard that it's unbelievable.
As usual, OpenBSD documentation is a dream come true. Thank you, guys.
Knowledge is power; knowledge shared is power lost.
So it's fair to say that Chrony isn't suitable for running on stratum 1 servers, of which there are a few hundred, maybe up to at most a few thousand publically available in the world[1]. For the millions of Linux servers, laptops and desktops that aren't and will never be stratum 1 NTP servers Chrony should be just fine, shouldn't it?
Yes, I think Chrony is fine for most typical unauthenticated leaf-node (client-only) usage, but I still don't recommend it for the thousands of public stratum 2 or higher (see pool.ntp.org, most are stratum 2 or 3) servers, or the thousands of corporate and organizational NTP servers. For usage as a server, with a full-time network connection, I don't know of any compelling reason to use Chrony over NTPD or OpenNTPD.
Personally I can't see any reason to believe Chrony is more secure than either NTPD or OpenNTPD. Being new, or even saying that Chrony is secure, and programming really, really carefully, doesn't make it so.