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