“Openntpd is not vulnerable.” | Hacker News Reader

“Openntpd is not vulnerable.”

article.gmane.org

126 pointse12e64 comments

Around 10 years ago it was written by Henning, at my request because the ntpd source code scared the hell out of us

And this is what I like about the OpenBSD community.

Another bit I find interesting

>At the time communications with the ntp team showed they had little interest in removing unused functionality from the ntp.org code, or any help with our form of source code audit.

Am I the only one who enjoys removing unused code? My favorite commits are the ones with negative net lines. This might be a liberal usage of the word "unused" though...

When I evaluate programmers I give effectively three times as much credit for removing a line of code than adding one. Sort of .5 for adding a line, 1.0 for changing a line, and 1.5 for reducing by a line. The principle being that well understood code should converge on the simplest correct solution over time.

Nice take on the whole "perfection is achieved, not when there's nothing left to add, but when there's nothing left to take away" thing!

One of my most productive days was throwing away 1000 lines of code - Ken Thompson

Deleted code is debugged code. — Jeff Sickel

I wouldn't say I enjoy removing unused code, but I definitely feel like I've accomplished something when I do.

Because it was a rewrite, the major benefit in openntpd is that it priviledge seperated. If problems like these were found, they would not be realistically exploitable. Furthermore openntpd is a modern piece of code <5000 lines long written using best known practices of the time,

And it very probably has zero memory safety bugs (pretty easy in 4,000 lines of code, as measured in a tarball I just downloaded), and privsep provides further defense at the cost of adding a lot of complication to the code... but I'm getting bored of this approach to security. For new code - I know openntpd is not new code, but I don't think this approach is popular in general yet - why not switch to Go or (when it's stable) Rust, or even JavaScript or Lua, and end up with essentially zero chance of such bugs being possible, regardless of how carefully or not the code was written, without the need for any privilege separation code? For something like NTP or SSH or most of the other daemons written in C people have sitting around, with the possible exception of high performance HTTP servers, the CPU overhead of any those languages is very unlikely to be noticeable (and privsep has overhead anyway).

(Admittedly, this would not help with non-memory-safety attacks such as NTP amplification...)

In particular, I'm going to make a bold claim: for OpenBSD to continue to release new daemons written in C, as it does, is irresponsible for a security-focused distribution. As much as they like the language - I do too -, as much as the whole expertise and design of the project is based on C, such that there is a naturally huge disincentive to switch languages, and as much as OpenBSD is able to minimize (but not eliminate) security advisories of this type, memory corruption is so dangerous that building a truly secure system requires making as much code as possible immune to the possibility of it.

(Hmm, I guess running AddressSanitizer in production would be nearly as good.)

I agree but I also see the counterpoint: a further abstraction layer (or VM) between language and iron can make it more difficult to identify abuses / edge cases, which is where security holes naturally hide. C compilers are very well-understood at this point, they are "the devil you know" so to speak.

Indeed, not to mention the fact the there are lots of folks who need to use the OS on modest hardware (embedded devices for example) and having additional runtimes for a language like Go or Javascript (god save us) is kind of out of the question.

Rust seems to be a saner alternative, but isn't production ready.

I could argue that there has actually been more serious bugs in applications written in "safe" languages (Ruby, PHP etc.) than in contemporary C applications.

After all, the bugs you describe is only one among many possible security problems that can arise in an application. Another big problem is ignorance of abstractions (oh, you thought this was a bytestring? turns out, it's actually dependent on your run time platform..). Straight up C is a lot more clear to read in that regard.

OpenBSD has none of those languages in the base OS; given they won't update gcc or switch to clang, Lua is the only one that they could support (NetBSD has it in base) but there is not a lot of system software written in Lua (alas). It doesn't have a depth of libraries that Go does. JavaScript would probably never pass review, so Rust is possibly a future option, unless a system programming community springs up around Lua.

Rust needs LLVM for code generation. Realistically they could only trust an interpreted language like (non-jit) Lua.

Or they could adopt ZeroVM/NaCl, which would shift the balance towards compiled languages again.

FWIW, the default Go compiler doesn't depend on GCC or Clang, and doesn't do as many optimizations which could be dangerous or buggy, which I gather is the main problem with adopting LLVM?

(I don't have much experience with Go, though.)

AFAIK neither Rust nor Go supports all the platforms that OpenBSD runs on.

The default compiler only supports x86, amd64, arm, so would need support added for mips, ppc, etc etc.

For those interested about the srand comment I believe he was referring to arc4random https://www.youtube.com/watch?v=aWmLWx8ut20

It's probably the fact that using time() for seeding a PRNG is a really poor choice.

Especially if your clock is synced with every other clock in the world.

Here's what happens when you do that:

http://alt.org/nethack/player-all.php?player=WowDeath

Full article here: http://taeb-nethack.blogspot.com/2009/03/predicting-and-cont...

It isn't a problem if all you need is a deterministic sequence of numbers that are pseudo-random like what rand() provides. Not every use of a PRNG involves cryptographic security or potentially dangerous exposures of internal state.

There are concerns with using time() as a seed other than security. Besides, consider what you are typically trying to express: initialize my PRNG with a random seed. Almost never are you trying to express: initialize my PRNG so that all runs in the same second will behave identically.

If you're generating random test case input on a single machine, time() is a perfectly reasonable way to seed a PRNG. A super-robust entropy source isn't a necessity when you just want something nominally random between intermittent runs.

...nominally random between intermittent runs.

That's a lot of caveats. Suppose you want to run multiple times in one second. Suppose you want statistically uniform random numbers to ensure even coverage of test cases.

Also if your clock resets on boot for some reason, and boot time is predictable.

For test case generation, I'd argue that you want the opposite of a time initialised random number generator. You'd want a deterministic seed for your random number generator, so you can repeat if required.

Why don't you use this sequence in such a case?: 0, 1, 2, 3, 4, 5, 6, 7, 8, ...

oh thats also a good point, but it would be solved with arc4random :-)

In some cases, yes.

Some simulations want to have the same sequence of numbers. Seems like a fundamental design misunderstanding in nethack, however.

> Some simulations want to have the same sequence of numbers.

srand(time(NULL)); does not provide that.

The point is, if you want a repeatable sequence, ask for it. If you want a truly random sequence, ask for it.

What you don't want is a repeatable random sequence that you, the programmer, incorrectly think is truly random. But rather a lot of invocations to srand turn out to be this case, rather than either of the legitimate two.

Too bad openntpd isn't standards compliant.

Fortunately, phk is already fixing ntpd. http://phk.freebsd.dk/time/index.html

"isn't standards compliant" how?

I believe gonzo meant "isn't portable", as OpenNTPD uses OpenBSD-only APIs. See this cousin thread: https://news.ycombinator.com/item?id=8778577 .

Yes, this non-portability is part of the openbsd playbook and strategy. There is a "non-portable" version of libressl, too.

There's a non-portable version of OpenSSH too. This strategy produces high-quality software while making developers' lives easier. (All in my highly-biased opinion)

It would be no more difficult for OpenBSD to produce one version, but that wouldn't fit with the strategy.

I don't see why the OpenBSD developers would want to avoid their strategy of producing secure code.

OpenNTPd is not really an implementation of NTP, it is an implementation of SNTP -- the Simple Network Time Protocol. There are a lot of things it doesn't even attempt to do which are covered in the NTP standard.

For serious. It doesn't even support the monitor command. How else am I supposed to amplify my DDOS traffic?

Turning off mon is part of the recommended configuration for a year now.

http://www.pool.ntp.org/join/configuration.html

Not that openntpd isn't invited to be a part of the NTP pool(s).

I thought Linux distributions stopped using ntpd a couple of years ago.

On Fedora, which powers the computer I'm writing this from, Chrony is in use, not ntpd, so I guess my PC is immune from whatever is floating out there.

Ubuntu has ntpd.

You can remove it and install Chrony.

Code has bugs. The less code you write, the less bugs you have. It's pretty simple really. OpenBSD has always done this well and taken a lot of criticism for it.

Excerpt from our several year old netbsd build scripts with annotations:

    install_openntpd() {
      install_from_source net/openntpd ### via pkgsrc
      cp /usr/pkg/share/examples/rc.d/openntpd /etc/rc.d/
      replace_service 'ntpd' 'openntpd' ### idempotently edits rc.conf to ensure ntpd=NO and openntpd=YES
    }

The openntpd default pool.ntp.org is a sane default that also doesn't leak host OS information as do most NTPd-based default confs.

"The portable version is outdated and in need of a maintainer." - http://www.openntpd.org/

The most recent version for OpenBSD is 4.6 while the "portable" one is 3.9 .

The OpenBSD 5.6 release notes http://www.openbsd.org/plus56.html show changes, so the non-portable version is being updated. You will see changes in previous releases.

> The OpenBSD 5.6 release notes http://www.openbsd.org/plus56.html show changes

I don't see anything about openntpd on that page. Are you makign stuff up?

Checking CVS[1] I see there are a few changes recently (4 weeks, 6 weeks, 2 months, ...) so it is being maintained.

1. http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/ntpd/

> I don't see anything about openntpd on that page. Are you makign stuff up?

The ntpd they mention is OpenNTPD see http://www.openbsd.org/faq/faq6.html#OpenNTPD

So, no, I am not "makign stuff up".

Dudes... I don't really care... I just want a way to synchronize my VPS clock with that of other, established, secure clocks... because DigitalOcean (okay, go ahead and downvote me) is not quite synched, and neither is Linode, and my server!!! Oh good Lord my server don't know the time at all! Dudes... just agree on something that I can install SIMPLY... 'cuz the infighting between ntp and openntp ain't nothing that I care to be involved with... JUST MAKE IT EASY!!!!

What are you whining about? What DO, Linode, etc. Have to do with anything????

OpenNTPd is extremely easy to configure. The problem is that it's not the default choice while, apparently, it should be. Same goes with almost all OBSD-derivates (OpenSMTPd, OpenSSHd, OpenNTPd, etc.).

Here is the first guide at google: https://wiki.archlinux.org/index.php/OpenNTPD

Feel free to ask, if you feel that there's something exotic that needs to be done before getting OpenNTPd to work.

> What are you whining about? What DO, Linode, etc. Have to do with anything????

Well, there's a good argument to be made that your VPS provider should be running an accurate time daemon (whatever that might be), and you should just have paravirtualized access to the current time, instead of every VM being expected to run some form of ntpd on its own, and the hypervisor track scores of virtual clocks.

There's even a good argument to be made that running the NTP algorithm in a VM doesn't work: https://www.usenix.org/legacy/event/osdi10/tech/full_papers/...

It's also documented best practice, at least with VMware and Xen.

Oh I see. I didn't knew that, I just connected the NTPd daemons either to the default NTP server or to the ISPs/Provider's NTPd server. Hm, didn't knew that VM had such issues with time servers.

You can also use timedated, an optional daemon packaged with systemd. Works really well for me, I just turned it on and it hasn't complained since.

The command you'll want to run is: # timedatectl set-ntp true

And it'll have you within a deep fraction of a second from a decent timeserver in about ten seconds, and keep you there indefinitely.

NOTE: For the person who downvoted this because they don't like systemd, seriously, you need to find a better hobby.

Also downvoted it because you'd be insane to trust systemd for this.

timedated isn't an improvement, it's just a new attempt at the code. In five years, you can recommend it.

For the moment, let's leave systems code to the people who understand it.

Blah, blah, blah.

You shouldn't discount everyone but the OpenBSD guys just because ntp.org's ntp is a 200kloc overgrown, underengineered mess.

It offers a good out for people who would otherwise use ntp.org's ntp, and at least it's about 200x less complex(1056 lines of C). Stasticially speaking, it's unlikely to be as faulty.

Timedated is an improvement even if just for the fact that it's incredibly simple to operate. You press a button and you're synchronized; very little to mess up.

I use OpenNTPD on my OpenBSD boxes, but that doesn't make me immune to alternatives.

Unfortunately, the OpenBSD "community" is all over HN.

You're being downvoted because this article is about the security of NTP implementations, yet your basis for recommending systemd-timesyncd is that it "works really well" for you. Well, ntpd worked well for me too but that didn't make it secure. You offer no basis for thinking systemd-timesyncd is secure, and yet there are many indications that it might be insecure: 1.) it's new, 2.) it wasn't designed with security in mind (unlike openntpd), and 3.) systemd's other reimplementation of a complex, hard-to-secure, UDP-based protocol (DNS) was discovered to lack even the most basic security protections[1].

Even someone who likes systemd's init system functionality should think really hard before using systemd's DNS and NTP appendages. This kind of stuff needs the attention of security experts. It can't just be reimplemented as an afterthought and be secure.

[1] http://seclists.org/oss-sec/2014/q4/592

It being a simple NTP client and not a server means that it has a vastly reduced attack surface. That's good. But that doesn't mean we shouldn't wait and see how buggy it actually is.

And their named DNS daemon was to be a stub resolver. Then it grew a cache. And now it seems to have developed a insecurity that most other DNS daemons out there dealt with a decade ago...

And if the one server timesyncd selects is a falseticker it will keep you there (where there is not equal to UTC) indefinitely too.

If you want an alternative check out chrony: http://chrony.tuxfamily.org/

Oh I'm very keen on to see "I am using an optional email client packaged with systemd!". Good times for Linux community. Next debate recommendation from me: Should we call distributions GNU/Linux or systemd/Linux?

Reply on news.ycombinator.com