NTPsec’s beta is released

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.

62 comments

  1. Modern society depends on this sort of deep infrastructure to function. Thank you Eric and the rest of the team!

  2. @Jakub Narebski, we will consider just about everything, including one of the several strbuf libraries.

    That consideration is tempered by the following non-exhaustive list of factors: license compatibility, stability/security/safety of it, how easily it integrates into the existing code, how messy is the external dependency and how hard is it to track and stay up to date, mental friction on code reviewers, does it add complexity to the work of drive-by developers, system integrators, and distro packagers, does it freeze out small and embedded systems as targets, etc etc etc.

    All that said, we will look at that strbuf library.

    1. >In http://www.ntpsec.org/removal-plan.html there is “The long-deprecated ntpdate program has been replaced with a shell wrapper around sntp.” but elsewhere you state that sntp was replaced by wrapper around ntpdig.

      sntp was renamed, after that page was first composed, to reduce NTPsec’s footprint in common namespace. Now we claim only binary names beginning with ntp for installables. The page didn’t catch up. Thanks for noticing.

      >In http://www.ntpsec.org/FAQ.html – what GPSD has to do with Google Maps?

      It’s beneath the Google Maps client in your Android phone, watching the on-board GPS and feeding the client location info.

      >Why ntpsec.org does not have favicon?

      !!!

      Because I spaced that detail. Shall go fix. I guess I’ll just shrink the clocktower image. (Yes, that’s my design.) I hope it’s intelligible at that size…

      1. >I hope it’s intelligible at that size…

        Sigh. It isn’t. I’m going to need a real artist. Any volunteers?

    1. >I’m not a real artist, but check your email for a quick favicon for ntpsec.

      Good enough; it’s live on the site now. How did you make it? I tried the obvious scale operation in GIMP, but the result wan’t usable because it quantized the tower sides out of existence.

  3. While you’re fixing things, you might want to fix the reference to ‘asciidoc.js’ in your page headers…

    1. >While you’re fixing things, you might want to fix the reference to ‘asciidoc.js’ in your page headers…

      No comprende. Why is this wrong?

  4. If I remember right you’re already being paid for this, but I just threw a bit of money in the tip jar anyway; this is important work.

  5. Asciidoc apparently uses JS for dynamically-generated TOCs and footnotes. Apparently the inclusion of asciidoc.js can be disabled by turning on the disable-javascript attribute.

    1. >Asciidoc apparently uses JS for dynamically-generated TOCs and footnotes.

      Which this site does not use. Still, I’ll try to clean this up.

  6. er, [link rel=”shortcut icon” href=”http://example.com/myicon.ico” /]

    grumble HTML strippers grumble

  7. >> In http://www.ntpsec.org/FAQ.html – what GPSD has to do with Google Maps?

    > It’s beneath the Google Maps client in your Android phone, watching the on-board GPS and feeding the client location info.

    When talking about Google Maps, I am most often thinking about https://maps.google.com – which does not need location service. Better way to state it would be that GPSD is used on each Android smartphone to provide GPS location info (does iOS use GPSD?).

  8. > Near-future releases will include security fixes currently under embargo.

    So… if the general cleanup would have taken care of one of the embargoed bugs, were you required to leave the bug in?

    1. >So… if the general cleanup would have taken care of one of the embargoed bugs, were you required to leave the bug in?

      Yes. That’s S.O.P.; you don’t ship code that might reveal a serious exploit before the embargo has given other implementations time to get their shit together. The usual timeout is 60 days; this is a compromise agreed on after much wrangling between hackers and InfoSec people (who favor short timeouts) on the one hand, and corporations (who. as a rule, would never disclose bugs or ship patches if they could get away with it).

  9. So the theory is that attackers are going to sift through thousands of lines of diffs and be able to tell which one represents a concrete exploit and which ones are your general cleanup?

    What if it turns out they can find it anyway by looking for the one strcpy you left in?

    1. >So the theory is that attackers are going to sift through thousands of lines of diffs and be able to tell which one represents a concrete exploit and which ones are your general cleanup?

      Yes. The category of bad guy InfoSec people call “Advanced Persistent Threat” – which is basically Chinese Army crackers and the Russian Mafia – has automated scanners looking for diffs that might be ‘sploit fixes.

      >What if it turns out they can find it anyway by looking for the one strcpy you left in?

      Then you’re screwed.


  10. That consideration is tempered by the following non-exhaustive list of factors: license compatibility, stability/security/safety of it, how easily it integrates into the existing code, how messy is the external dependency and how hard is it to track and stay up to date, mental friction on code reviewers, does it add complexity to the work of drive-by developers, system integrators, and distro packagers, does it freeze out small and embedded systems as targets, etc etc etc.

    All that said, we will look at that strbuf library.

    License compatibility might be a problem, as strbuf.{c,h} in Git is covered by the same license as Git, namely GPLv2. It is also certainly underdocumented.

    Certainly strbuf_add, strbuf_addf / strbuf_vaddf, strbuf_getline, strbuf_read_file are safer than strcpy, strcat, sprintf, getline, and probably easier to use (and safe against unchecked truncation) than strcat_s / strncat / strlcat / strcpy_s / strncpy / strlcpy / stpcpy.

  11. I like the website’s design policy, but it’s still missing navigation links from subpages to the main page. Dead-end pages aren’t among the good parts of 1990’s web design.

  12. > License compatibility might be a problem, as strbuf.{c,h} in Git is covered by the same license as Git, namely GPLv2.

    … though Git developers are amendable to license change / relicensing of code. It was done with the code that got into JGit, which is EDL (new-style BSD) licensed. Still, it was quite a bit of work to gather all those agreements.

  13. The category of bad guy InfoSec people call “Advanced Persistent Threat” – which is basically Chinese Army crackers and the Russian Mafia – has automated scanners looking for diffs that might be ‘sploit fixes.

    Eric, be careful about using the phrase “Advanced Persistent Threat”, even when, as here, you’re using it correctly. It has associations that give security researchers a nasty twitch because of two bogus usages which have turned into a running joke that isn’t funny any more. The first is marketing firms for security companies making vacuous claims that their product provides “protection from APT”. The other is companies which get breached by phishing or some similarly low-effort tactic and then scream “APT!” in effort to avoid looking incompetent to their shareholders. These two usages have become such a large share of all usage that people tend to immediately flip a bozo bit upon hearing it.

  14. > Then you’re screwed.

    Eh, I guess it was an oversimplification anyway. If it were really something that unsubtle it’d make more sense to just hold back the whole thing for the embargo period, so I assume it’s actually not. Just the whole mental image of “Fix everything except the known bugs” is amusing.

  15. Eric, what would happen if you fix an embargoed vulnerability _as a side effect_ of fixing something else?

    Case I’m thinking of is an embargoed vulnerability getting run over by an exclude-class-of-bugs tactic (like your achtung verboten on string handling gubbins).

    Or is that implying a lack of understanding of codebase that isn’t really permissible in the project architect/lead?

  16. Alex, what you’re describing is a common situation in a lot of projects, and it can get delicate. The general principle is that the publicly-observable behavior of the project team during the embargo should be indistinguishable from what it would be if the bug had never found. So, hardening work that was already planned prior to the report, which would incidentally have repaired the vulnerable code, should continue. At least, that’s the ideal. Any time this happens, though, there’s a risk that stakeholders will perceive it as a violation of the embargo, so it needs to be discussed with them in advance and politics may come into play.

  17. @Alex Goodwin – Unless I’m missing something, I think you just rephrased the same question that I already asked and he already answered.

  18. FWIW I just tried building/Installing on Arch Linux on Raspberry Pi.

    Minor problems but it basically builds OK AFAICT. However I was unable to figure out what the pps-tools equivalent is (the various RPi GPS NTP projects seem to have their own PPS implementations) so I suspect problems if trying to run as a reference server. But that

    Minor problems:
    1) when I run ntptime I get “sprintb buffer too small messages”
    [pi@alarmpi ntpsec]$ ntptime
    ntp_gettime() returns code 0 (OK)
    time d9f65fa7.a83a322c 2015-11-18T02:23:35.657, (.657138123),
    maximum error 862500 us, estimated error 0 us, TAI offset 0
    ntp_adjtime() returns code 0 (OK)
    modes sprintb buffer too small,
    offset -171.591 us, frequency -49.267 ppm, interval 1 s,
    maximum error 862500 us, estimated error 0 us,
    status sprintb buffer too small,
    time constant 7, precision 0.001 us, tolerance 500 ppm,

    2) Directories/files in /var/db/ not apparently created at install. E.g.

    [pi@alarmpi ntpsec]$ ntpdig jp.pool.ntp.org
    kod_init_kod_db(): Cannot open KoD db file /var/db/ntp-kod: No such file or directory
    2015-11-18 02:41:10.933862 (+0000) +0.001667 +/- 0.001432 jp.pool.ntp.org 60.56.214.78 s1 no-leap

    1. >FWIW I just tried building/Installing on Arch Linux on Raspberry Pi.

      My blog has many virtues, but it is not the NTPsec bugtracker. Please file these issues there; I think you might have the distinction of being the first.

  19. > My blog has many virtues, but it is not the NTPsec bugtracker. Please file these issues there; I think you might have the distinction of being the first.

    Second bug actually. And my second reported problem is actually a known documentation issue as I found out when I looked at the man page for ntpdig

  20. > My blog has many virtues, but it is not the NTPsec bugtracker.

    BTW. is there a bugtracker for NTPsec *web pages*?

  21. … and is there separate repository (or an orphan branch) for NTPsec web pages’ sources?

    1. >… and is there separate repository (or an orphan branch) for NTPsec web pages’ sources?

      There’s a separate repository.

  22. @Random832

    Yeah, looks like I did barge ahead thusly. Was wondering why my foot tasted like chicken.

    1. >Would NTPsec support (or perhaps it does already support) Network Time Security (NTS) protocol, and/or offer reference implementation of thereof?

      I have reached out to the authors of that Internet draft standard inviting them to work with us on implementation and interop testing. Later this morning I will be in a phone conference with the IETF working group on NTP, and expect this to be one of the topics discussed.

  23. Worth a blog post (and feel free to remove this comment)?
    Practically speaking Free Software must be open-source, but when does open-source become not Free Software:
    http://mjg59.dreamwidth.org/38467.html
    If it’s not practical to redistribute free software, it’s not free software in practice

  24. “the code has been very seriously security-hardened”

    Really? I thought you wrote it in C.

  25. esr:
    > > “the code has been very seriously security-hardened”

    Random Observer on 2015-11-21 at 05:55:33 said:
    > Really? I thought you wrote it in C.

    The big security problem with C is that you must do your own memory management, and most programmers just don’t.

    I am confident that any C or C++ code I write has correct memory management, and even more confident that when esr is through hardening any code, it has correct memory management.

    To the best of my recollection the only times I have ever had memory problems in code I sent to QA, was when using libraries that had their own idiosyncratic and unusual memory management practices.

    Memory management in C++ is semi manual, semi automatic A fully memory safe subset of C++ is under development with fully automatic memory management – though one is free to pragma outside the subset whenever you feel the need.

  26. I am confident that any C or C++ code I write has correct memory management, and even more confident that when esr is through hardening any code, it has correct memory management.

    I could go from here to China with examples of memory leaks and buffer corruption vulnerabilities I’ve seen in C code that came with exactly those assurances.

  27. @Random Observer –

    > > I am confident that any C or C++ code I write has correct memory management ….

    > I could go from here to China with examples of memory leaks and buffer
    > corruption vulnerabilities I’ve seen in C code that came with
    > exactly those assurances.

    Yeahbut – over here Eric talks extensively and in detail about what he has done to be able to make those assurances. James Donald, I don’t know about, because I have no particular examples.

    Of course one can make boastful and specious claims. I would submit Our Gracious Host is not doing so.

  28. This just in: Apple has released their Swift compiler as an open source project. Hopefully, this will result in all the time bombs in /bin getting replaced over time.

  29. Yeahbut – over here Eric talks extensively and in detail about what he has done to be able to make those assurances.

    Wow, look at all that work that isn’t necessary if you pick a better language in the first place.

    1. >Wow, look at all that work that isn’t necessary if you pick a better language in the first place.

      Are you even thinking? How was that an option?

      As I’ve noted here before, the time-service userbase is intensely conservative and risk-averse. You can’t sell them a rewrite from scratch. It has been tried multiple times, and failed.

      Besides, nobody offered to pay me to fix time service in Rust or Go or Dart or the hipster fad language of the week. After years of unrenumerated toil fixing the plumbing, that was pretty attractive.

  30. Hey Eric, I know you like C. I like it myself. It’s a fun little half-assed language that lets you do anything but write secure code.

    I’m not knocking you for sticking with what you enjoy, I’m just rejecting your statement that it’s seriously security-hardened. I can’t even count the number of times that I’ve heard “this time for sure!’ w/r/t the security of a C codebase that turned out to be wishful thinking.

    1. >I can’t even count the number of times that I’ve heard “this time for sure!’ w/r/t the security of a C codebase that turned out to be wishful thinking.

      Fair enough. But engineering, like politics, is the art of the possible, and we’re stuck with C short of a ground-up rewrite that the userbase wouldn’t buy.

      I’m well aware of C’s inherent problems; when I say NTPsec has been seriously security-hardened I mean that it has been audited and armored as well as anyone knows how to do that. That is a meaningful statement, with consequences in defect rates, even if the guarantee is not and cannot be absolute.

      As for what I enjoy, I’d prefer to be writing Python or Lisp. But that’s not an option here.

  31. BTW. what are performance constraints on NTP classic / NTPsec use NTP server? It might be that only compiled languages allow for such use…

    Nb. I really should pick up “Secure Programming Cookbook for C and C++” by John Viega, Matt Messier

  32. I really should pick up “Secure Programming Cookbook for C and C++”

    Better known as “the great big book of wishful thinking”.

    1. >Better known as “the great big book of wishful thinking”.

      I think this is a bit too harsh. Yes, security is easier in a language with GC and much easier in a language designed for security proofs, but the state of the art in C verification tools has moved a lot in the last decade. I would now rate secure C programming as difficult, and requiring more methodological discipline than is usually managed, but not hopeless.

  33. It’s all Assembly at the bottom anyway. Odds are pretty good your special-snowflake secure programming language is implemented in C anyway.

Leave a Reply to Mark Atwood Cancel reply

Your email address will not be published. Required fields are marked *