>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.
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 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.
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 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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.).
> 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.
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'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.
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...
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.
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?
And this is what I like about the OpenBSD community.