Haven’t been blogging for a while because I’ve been deep in coding and HOWTO-writing. Follows the (slightly edited) text of an email I wrote to the NTPsec devel list that I I think might be of interest to a lot of my audience.
One of the questions I get a lot is: How do you do it? And what is “it”, anyway? The question seems like an inquiry into the mental stance that a systems architect has to have to do his job.
So, um, this is it. If you read carefully, I think you’ll learn a fair bit even if you haven’t a clue about NTP itself.
While most of the NTPsec team was off at Penguicon, the NTP Classic people shipped a release patched for eleven security vulnerabilities in their code. Which might have been pretty embarrassing, if those vulnerabilities were in our code, too. People would be right to wonder, given NTPsec’s security focus, why we didn’t catch all these sooner.
In fact, we actually did pre-empt most of them. The attack surface that eight of these eleven security bugs penetrate isn’t present at all in NTPsec. The vulnerabilities were in bloat and obsolete features we’ve long since removed, like the Mode 7 control channel.
I’m making a big deal about this because it illustrates a general point. One of the most effective ways to harden your code against attack – perhaps the most effective – is to reduce its attack surface.
Thus, NTPsec’s strategy all along has centered on aggressive cruft removal. This strategy has been working extremely well. Back in January our 0.1 release dodged two CVEs because of code we had already removed. This time it was eight foreclosed – and I’m pretty sure it won’t be the last time, either. If only because I ripped out Autokey on Sunday, a notorious nest of bugs.
Simplify, cut, discard. It’s often better hardening than anything else you can do. The percentage of NTP Classic code removed from NTPsec is up to 58% now, and could easily hit 2/3rds before we’re done,
You’ve heard me uttering teasers about it for months. Now it’s here. The repository is available for cloning; we’re shipping the 0.9.0 beta of NTPsec. You can browse the web pages or clone the git repository by one of several methods. You can “wget https://github.com/NTPsec/ntpsec/archive/NTPsec_0_9_0.tar.gz” to get a tarball.
This is an initial beta and has some rough edges, mostly due to the rather traumatic (but utterly necessary) replacement of the autoconf build system. Also, our range of ports is still narrow; if you’re on anything but Linux or a recent FreeBSD the build may not work for you yet. These things will be fixed.
However, the core function – syncing your clock via NTP – is solid, and using 0.9.0 for production might be judged a bit adventurous but wouldn’t be crazy. The next few beta releases will rapidly get more polished. Expect them to come quickly, like within weeks.
Most of the changes are under the hood and not user-visible. A few auxiliary tools have been renamed, most notably sntp to ntpdig. If you read documentation, you will notice that what’s there has been massively revised and improved.
The most important change you can’t see is that the code has been very seriously security-hardened, not only by plugging all publicly disclosed holes but by internal preventive measures to close off entire classes of vulnerabilities (by, for example, replacing all function calls that can produce buffer overruns with memory-safe equivalents.)
We’ve already established good relations with security-research and InfoSec communities. Near-future releases will include security fixes currently under embargo.
If you consider this work valuable, please support it by contributing at my Patreon page.
In the wake of the Ars Technica article on NTP vulnerabilities, and Slashdot coverage, there has been sharply increased public interest in the work NTPsec is doing.
A lot of people have gotten the idea that I’m engaged in a full rewrite of the code, however, and that’s not accurate. What’s actually going on is more like a really massive cleanup and hardening effort. To give you some idea how massive, I report that the codebase is now down to about 43% of the size we inherited – in absolute numbers, down from 227KLOC to 97KLOC.
Details, possibly interesting, follow. But this is more than a summary of work; I’m going to use it to talk about good software-engineering practice by example.
NTPsec is preparing for a release, which brought a question to the forefront of my mind. Are tarballs obsolete?
Sometimes you find performance improvements in the simplest places. Last night I improved the time-stepping precision of NTP by a factor of up to a thousand. With a change of less than 20 lines.
The reason I was able to do this is because the NTP code had not caught up to a change in the precision of modern computer clocks. When it was written, you set time with settimeofday(2), which takes a structure containing seconds and microseconds. But modern POSIX-conformant Unixes have a clock_settime(2) which takes a structure containing seconds and nanoseconds.