NTP Is The Latest Project Struck By Security Issues

[The Walking Glitch]

I ask because privilege escalation was mentioned.

Anyways, I wonder why it has not been rewritten to just have a minimal daemon for just opening the port, and acting as a go-between between the time setting and a completely unprivileged program which does the actual network synchronization.

To adjust the system clock - we can't let just any user do that. Most systems have a way for NTP to do that after dropping from root to a lesser-privileged user (e.g. /dev/clockctl on NetBSD).

Also, to open the privileged (low-numbered) port 123; but it can drop its privileges after doing that. Debian/Ubuntu normally configures it to do that; NetBSD can optionally do that, and restrict it to a chroot also; OpenBSD has entirely its own ntpd, less featureful but more likely secure.

[Delgarde]

But maybe we need to replace C for system software and daemons with something else, like Rust?

That would help some categories of bug, certainly - eliminating buffer overflows and the like, bugs that can only occur in an environment where you can accidentally poke around in the wrong bit of memory. That's why we saw the story yesterday on server-side XCB, where the Xorg guys are looking to generate the wire layer from protocol specs, instead of hand-writing it.

But that hardly avoids all security bugs. You can't overflow into unallocated memory, but you can still get buffer size errors with allocated buffers. And you can still get security issues from stuff like using a weak random number generator (one of the cited NTP bugs), and things like weak crypto resulting from a coder who doesn't properly understand salts and hashes and all the things you need to understand if you need strong crypto.

[strcat]

ntpd can be run as non-root but it holds onto the CAP_SYS_TIME capability. It's set up this way by default in the packages for these daemons (chrony / ntpd) on Arch Linux and I expect that other major distributions are doing the same. However, privilege escalation exploits in the kernel are pretty common so it shouldn't be very reassuring. This is why running a kernel with PaX / grsecurity is so important. For example, the recent CVE-2014-9322 is prevented by PaX's UDEREF feature (prevents kernel from accidentally dereferencing userspace pointers).