OpenBSD Releases a Portable Version of OpenNTPD 79
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!
Re:Why can't anyone write secure software? (Score:5, Funny)
Hey, speak for yourself! I wrote a secure "hello world" once....
Re: (Score:1)
Hey, speak for yourself! I wrote a secure "hello world" once....
Did you checked and managed the return value?
Re: (Score:3, Funny)
Re: (Score:1)
Did you write a secure compiler for it, too? [bell-labs.com]
Re: (Score:2)
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 me
Re: (Score:2)
.
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 fron
Re: (Score:3, Informative)
Re: (Score:1)
Admit it. It's a large, fat piece of shit that nobody should be running. OpenNTPD in fact works perfectly as an accurate NTP (not SNTP) server AND client for more than 10,000 devices on my network.
Comment removed (Score:4, Interesting)
Re: (Score:2)
It would be nice if the whole world got the BCP38 memo. But they haven't. I'm a network operator. I got off my lazy ass and firewalled all of the ntp.org servers on my network, that customers didn't enable and had no idea were even running, courtesy of Cisco and various Linux distributions. Reality is a bitch.
Re: (Score:2)
When I trace routed several of the servers retu
Re: (Score:1)
Re: (Score:2)
So.. Yeah... I may have to give the pool another shot.
Thanks for your experience
Re: (Score:1)
Re: (Score:2)
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
IMO failure to implement BCP38 is no excuse for protocols to not sufficiently deal with the Internet as it exists today. Solution for DNS is the same solution previously applied to TCP to mitigate SYN exhaustion attacks.
https://tools.ietf.org/html/dr... [ietf.org]
All remaining deployed protocols susceptible to cheesy amplification attacks can and should be fixed regardless of status of BCP38. None of it is rocket science.
Re: (Score:2)
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
Re: (Score:2)
Then I guess he's not working on OpenBSD.
http://www.openbsd.org/errata5... [openbsd.org]
Mathematics (Score:5, Interesting)
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.
Re: (Score:3)
.
I have ten servers for which the 100 millisecond accuracy of OpenNTPD is perfectly fine. I have one server where I may need more accuracy than that.
So I'd rather run the risk of having only one server with the bloated mess of ntp, and having a valid alternative for my other ten servers.
...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.
... Sorry, but your comment is just a blatant, "Look at us, the ntp project provides more accuracy, so just ignore everything else that is wrong with it."
To my eyes, it looks like the ntp pro
Re: (Score:2)
I have ten servers for which the 100 millisecond accuracy of OpenNTPD is perfectly fine.
That's nearly a tenth of a second!
Re: (Score:2)
Chrony is a complete working implementation of the NTP protocol. NTPD gets its knickers in a twist at the slightest excuse and sometimes ends up stepping the time even though it has perfectly good Internet connectivity and a reasonably good internal clock. Chrony keeps steady time even if Internet access is intermittent. It never gets confused and picks a falseticker pretending to be stratum one instead of a stratum 3 with correct time, unlike NTPD.
It even has interfaces to GPS clocks or other hardware cloc
Re: (Score:1)
Yes it implements the protocol. So does OpenNTPD -- up to v3 or v4 for SNTP. Nobody is refuting that. There is more than just the protocol specs.
Re: (Score:3)
Chrony is a complete working implementation of the NTP protocol.
You mean complete except for broadcast/multicast mode, or authentication based on public-key cryptography. Some basically it's a good client and a unauthenticated / inefficient (network) server.
It also makes some pretty misleading claims; Chrony can usually synchronise the system clock faster and with better time accuracy [tuxfamily.org] except it never explains how it can possibly achieve better time accuracy than NTPd.
Chrony does handle a number of client usage scenarios better than NTPD (namely non-permanent network co
Re: (Score:2)
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?
[1] ntp.org currently lists 304 publcically available stratum 1 servers http://support.ntp.org/bin/vie... [ntp.org]
Re:Chrony (Score:2)
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 OpenN
Re:Mathematics (Score:5, Informative)
[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.
Re: (Score:1)
I bet if you spent more time educating your customers and pricing your services according to how up-to-date they kept their software instead of acting like a moronic Neanderthal on Slashdot you'd be a lot happier.
Re: (Score:2)
Re: (Score:1)
This is moronic.
Yes, yes indeed. Not in the way you think, though.
NTP exists to provide accurate time. If all you need is only somewhat sane clock values, then NTP is overkill and SNTP (or timed, or ICMP TIMESTAMP) might serve you just as well. But now you go and claim that because "most people" don't need that super-duper NTP thing, it's fine to break basic functionality for those (few? you'd be surprised) people for whom it actually matters quite a lot.
That is akin to, say, centralising IT support, then defining three ki
Re: (Score:2)
90% of Windows domains needs little more than a net time command in a login script to stay within suitable tolerances for most things. I know, I've done it when external NTP wasn't an option and internal NTP was overkill.
That's not the problem. People are suggesting we throw away ntpd and use alternate ntpd that, for those who need NTP, aren't viable alternates.
And they're suggesting it for a couple of security problems that were found, fixed and patched before they could ever be exploited. And, worst ca
Re: (Score:3)
Define 'accurate.'
I need submillisecond time here (where here is a radio astronomy observatory), with no discontinuities like an SNTP client will insert (stepping time is not 'accurate'). That's why I have three stratum 1 local NTP servers that use Agilent Z3816A GPS-disciplined clocks.
SNTP != NTP and is totally unsuited for any use that cares about real continuous, accurate, time. Read the 'time-nuts' mailing list at febo to see what real accuracy is.
Re: (Score:2)
I run three local (private) GPS-synced stratum 1 NTPD instances here. Stratum 1 is hard to get right, as hard as getting security right.
Very very different... (Score:4, Informative)
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.
Re: (Score:1)
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).
Re: (Score:2)
Please enlighten us.
There are other alternatives already (Score:5, Interesting)
Like chrony.
I wouldn't recommend openntpd because it isn't an implementation of ntp
Re: (Score:1)
Nothing to see here...
System D already has a built in NTP client, so we Linux people can use that.
Re: (Score:3)
SystemD does not have an NTP client. It has an SNTP client. Just like OpenNTPD.
Re: (Score:1)
WOW, here I was, running a good old System D troll ("Who in the flying fuck would implement NTP in an init system! ha ha ha") and I guess I wasn't trolling hard enough--you're right! Those guys actually did it:
https://wiki.archlinux.org/index.php/systemd-timesyncd
Things really *are* bad, aren't they?
I'd make a joke about System D including a NoSQL database, but they probably already have one of those already...
Re: (Score:2)
Things really *are* bad, aren't they?
Yes. They are that bad. Read the threads about Gnome vs. systemd-timesyncd vs. Chrony and weep.
http://www.spinics.net/lists/f... [spinics.net]
And Poettering in his usual ignorant condescending style:
http://www.spinics.net/lists/f... [spinics.net]
Re: (Score:2)
Wow, that thread is really depressing. So the decision path for what ships with Fedora has been simplified to: what package isn't broken by systemd? Suitability for a task and technical merits aren't even a consideration any more...
Re: (Score:2)
Here's a gem from Poettering [spinics.net], where he dismisses basic security (why would you not implicitly trust unauthenticated packets from some random internet server?), as well as displays his total lack of awareness of the capabilities of the existing software he's bent on replacing (super-NIH syndrome... writing a simplistic replacement to ntpd and chronyd without even knowing what they currently do).
Yikes.
Re: (Score:2)
I assumed it was a troll myself, and giggled 'haha, systemd with an ntp client, lolz" and then boom, mind blown, there really is one? jeez.
Re: (Score:1)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:1)
I assume you've used it? because it keeps time on my servers and serves that time to well over 10k devices on my network!
Re: (Score:1)
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.
openntpd is buggy (Score:1)
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.
Re: (Score:1)
It's not a bug.
The commit log states this:
when a dns lookup fails at parse time, do not abort but try again
to resolve the hostname every 60 seconds
fixes ntpd invocations before e. g. a dialup link is established and such.
as we want ntpd to be a "fire and forget" background daemon it should
cope with such situations.
tested by many
Relevant diff: http://cvsweb.openbsd.org/cgi-... [openbsd.org]
(I'm assuming that the "bug" you found is that it's comparing the return value to -1 when the host() function can only return 0 or 1)
ntpdate (Score:1)
Mmmmm (Score:2)
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 genera
Best documentation ever (Score:2)
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.