
“Openntpd is not vulnerable.” - e12e
http://article.gmane.org/gmane.os.openbsd.tech/40107/
======
joshbaptiste
_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.

~~~
rtpg
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...

~~~
ChuckMcM
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.

------
comex
_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.)

~~~
justincormack
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.

~~~
comex
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.)

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

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

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

~~~
kevin_thibedeau
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.

~~~
detrino
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.

~~~
kevin_thibedeau
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.

~~~
nitrogen
_...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.

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

------
gonzo
Too bad openntpd isn't standards compliant.

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

~~~
djmdjm
"isn't standards compliant" how?

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

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

~~~
djmdjm
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)

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

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

------
finid
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.

~~~
wglb
Ubuntu has ntpd.

~~~
finid
You can remove it and install Chrony.

------
w8rbt
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.

------
fubarred
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.

------
stefantalpalaru
"The portable version is outdated and in need of a maintainer." \-
[http://www.openntpd.org/](http://www.openntpd.org/)

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

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

~~~
finid
> The OpenBSD 5.6 release notes
> [http://www.openbsd.org/plus56.html](http://www.openbsd.org/plus56.html)
> show changes

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

~~~
protomyth
> 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](http://www.openbsd.org/faq/faq6.html#OpenNTPD)

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

------
jgwest
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!!!!

~~~
atmosx
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](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.

~~~
geofft
> 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/...](https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Broomhead.pdf)

~~~
atmosx
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.

------
microcolonel
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.

~~~
agwa
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](http://seclists.org/oss-
sec/2014/q4/592)

~~~
Ded7xSEoPKYNsDd
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.

~~~
digi_owl
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...

