Monthly Archives

September 2017

Securing Network Time

By | Blogs | No Comments

Since its inception the CII has considered network time, and implementations of the Network Time Protocol, to be “core infrastructure.” Correctly synchronising clocks is critical both to the smooth functioning of many services and to the effectiveness of numerous security protocols; as a result most computers run some sort of clock synchronization software and most of those computers implement either the Network Time Protocol (NTP, RFC 5905) or the closely related but slimmed down Simple Network Time Protocol (SNTP, RFC 4330).


There are several different implementations of NTP and SNTP, including both open source and proprietary versions. For many years the canonical open source implementation has been ntpd, which was started by David Mills and is now developed by Harlan Stenn at the Network Time Foundation. Parts of the ntpd code date back at least 25 years and the developers pride themselves in having the most complete implementation of the protocol and having a wide set of supported platforms. Over the years forks of the ntpd code have been made, including the NTPSec project that seeks to remove much of the complexity of the ntpd code base, at the expense of completeness of the more esoteric NTP features and breadth of platform support. Others have reimplemented NTP from scratch and one of the more complete open source alternatives is Chrony, originally written by Richard Curnow and currently maintained by Miroslav Lichvar.

The CII recently sponsored a security audit of the Chrony code, carried out by the security firm Cure53 (here is the report). In recent years, the CII has also provided financial support to both the ntpd project and the NTPSec project. Cure53 carried out security audits of both ntpd and NTPSec earlier this year and Mozilla Foundation’s Secure Open Source (SOS) project funded those two audits. SOS also assisted the the CII with the execution of the Chrony audit.

Since the CII has offered support to all three projects and since all three were reviewed by the same firm, close together in time, we thought it would be useful to present a direct comparison of their results.


Full report PDF

The ntpd code base is the largest and most complex of the three and it carries a lot of legacy code. As a result, unsurprisingly, it fared the worst of the three in security testing with the report listing 1 Critical, 2 High, 1 Medium and 8 Low severity issues along with 2 Informational comments. It should be noted that these issues were largely addressed in the 4.2.8p10 release back in March 2017. That said, the commentary in the report is informative, with the testers writing:

“The general outcome of this project is rooted in the fact that the code has been left to grow organically and had aged somewhat unattended over the years. The overall structure has thus become very intricate, while also yielding a conviction that different styles and approaches were used and subsequently altered. The seemingly uncontrolled inclusion of variant code via header files and complete external projects engenders a particular problem. Most likely, it makes the continuous development much more difficult than necessary.”

As a result, it seems quite likely that there are more lurking issues and that it will be difficult for the authors to avoid introducing new security issues in the future without some substantial refactoring of the code.

As mentioned above, ntpd is the most complete implementation of NTP and as a result is the most complex. Complexity is the enemy of security and that shows up in this report.


Full report PDF

As mentioned previously, the NTPSec project started as a fork of ntpd with the specific aim of cleaning up a lot of the complexity in ntpd, even if that meant throwing out some of the less-used features. The NTPSec project is still in its early days; the team has not yet made a version 1.0 release, but has already thrown out nearly 75% of the code from ntpd and refactored many other parts. Still, the security audit earlier this year yielded 3 High, 1 Medium and 3 Low severity issues as well as raising 1 Informational matter. The testers comments again were telling:

“On the one hand, much cruft has been removed successfully, yet, on the other hand, the code shared between the two software projects bears tremendous similarities. The NTPsec project is still relatively young and a major release has not yet occurred, so the expectations are high for much more being done beforehand in terms of improvements. It must be mentioned, however, that the regression bug described in NTP-01-015 is particularly worrisome and raises concerns about the quality of the actions undertaken.

In sum, one can clearly discern the direction of the project and the pinpoint the maintainers’ focus on simplifying and streamlining the code base. While the state of security is evidently not optimal, there is a definite room for growth, code stability and overall security improvement as long as more time and efforts are invested into the matter prior to the official release of NTPsec.”

The NTPSec has made some significant technical progress but there is more work to do before the developers get to an official release. Even then, the history of the code may well haunt them for some time to come.


Full report PDF

Unlike NTPSec, Chrony is not derived from the ntpd code but was implemented from scratch. It implements both client and server modes of the full NTPv4 protocol (as opposed to the simplified SNTP protocol), including operating as a Stratum 1 reference server, and was specifically designed to handle difficult conditions such as intermittent network connections, heavily congested networks and systems that do not run continuously (like laptops) or which run on a virtual machine. The development is currently supported by Red Hat Software and it is now the default NTP implementation on their distributions.

In the 20+ years that I’ve worked in the security industry I’ve read many security audits. The audit that the CII sponsored for Chrony was the first time that I’d used Cure53, and I had not seen any previous reports from them, so when I received the report on Chrony I was very surprised. So surprised that I stopped to email people who had worked with Cure53 to question their competence. When they assured me that the team was highly skilled and capable, I was astounded. Chrony withstood three skilled security testers for 11 days of solid testing and the result was just 2 Low severity issues (both of which have since been fixed). The test report stated:

“The overwhelmingly positive result of this security assignment performed by three Cure53 testers can be clearly inferred from a marginal number and low-risk nature of the findings amassed in this report. Withstanding eleven full days of on-remote testing in August of 2017 means that Chrony is robust, strong, and developed with security in mind. The software boasts sound design and is secure across all tested areas. It is quite safe to assume that untested software in the Chrony family is of a similarly exceptional quality. In general, the software proved to be well-structured and marked by the right abstractions at the appropriate locations. While the functional scope of the software is quite wide, the actual implementation is surprisingly elegant and of a minimal and just necessary complexity. In sum, the Chrony NTP software stands solid and can be seen as trustworthy.”

The head of Cure53, Dr. Mario Heiderich, indicated that it was very rare for the firm to produce a report with so few issues and that he was surprised that the software was so strong.

Of course just because the software is strong does not mean that it is invulnerable to attack, let alone free from bugs. What it does mean however is that Chrony is well designed, well implemented, well tested and benefits from the hindsight of decades of NTP implementation by others without bearing the burden of legacy code.


From a security standpoint (and here at the CII we are security people), Chrony was the clear winner between these three NTP implementations. Chrony does not have all of the bells and whistles that ntpd does, and it doesn’t implement every single option listed in the NTP specification, but for the vast majority of users this will not matter. If all you need is an NTP client or server (with or without reference clock), which is all that most people need, then its security benefits most likely outweigh any missing features.



The security audit on Chrony was funded by the CII but the Mozilla SOS project handled many of the logistics of getting the audit done and we are very grateful to Gervase Markham for his assistance. Mozilla SOS funded the audits of ntpd and NTPSec. All three audits were performed by Cure53.

1,000 Projects Registered for the CII Best Practice Badge, 100 Badges Granted and Prizes!!!

By | Blogs | No Comments

In May of last year the CII launched its Best Practice Badge program. Our goal was to raise awareness of development processes and project governance steps that will help projects have better security outcomes. By giving project maintainers a list of actionable items that will know improve security, teaching them why these steps lead to improvement and showing them how to implement them, we can raise security standards and help projects get better at delivering secure products. By offering a visual “badge” we can make it easier for consumers of open source projects to see which projects take security seriously. More recently, in June of this year, we added new Silver and Gold levels to the badges, to allow projects that make further efforts to drive security improvements to show off their commitment.

We recently issued our 100th Badge to a passing project. A few days later, we had our 1,000th project sign up for the Best Practice Badge program. Our goal for the Best Practice Badge is to be a recognisable mark of commitment to security by projects. For for any mark to gain recognition, it needs to be used and on display.  In light of that fact, we are delighted that the Best Practice Badge recently passed these two major adoption milestones.

Some people have questioned why the pass rate is only 10 percent. The fraction of projects getting a badge has been fairly stable for a while, even as the number of registered projects continues to grow, as can be seen from the project statistics page. When we set up the program it was very much our intent that this should not be some “rubber stamp” process but that projects would need to work to get their badge. To date nearly every project has had to make some improvement in order to achieve a badge, which indicates that the program is actually moving the needle on Open Source Security.

Several projects have given us feedback on the badging process and there are several topics that came up over and over again. Common issues that often need to be fixed include:

  • not supporting a secure way to access the project web site (or not having a valid certificate for the site),

  • not performing automated testing,

  • not performing any sort of code analysis;

  • and not having a publicly documented process for reporting security vulnerabilities.

Other important changes projects have made as a result of going through the badge process include:

  • removing insecure cryptographic algorithms,

  • adding unique version numbers for each release,

  • documenting release notes and the contribution process, and

  • including coding style guidelines for contributions.

History shows that these sorts of steps can improve the security outcomes for projects so we are delighted that all of the passing projects are now taking these steps.

CII KubernetesOn to Silver and Gold

As well as the huge progress we have made with getting projects to a “passing grade,” the CII Best Practice Badge program recently launched its enhanced Silver and Gold badges. These higher level badges add a number of extra criteria on top of the passing level and make mandatory some of the criteria that are recommended at the lower levels. These higher levels of give our passing projects some new stretch goals to which they can aspire.

Today we are delighted to announce that now not only do the the higher level badges bring glory and fame but prizes as well! The maintainers who complete the Silver badge process of the first 50 projects will each receive a bag of Linux Foundation and CII branded swag (probably a hoodie, t-shirt and some other stuff; we’ve not quite pinned the details down yet). Furthermore, each maintainer who completes the badge process of the first 5 projects to have a Gold badge validated will be invited to attend the Linux Foundation-organised conference of their choice, along with an invitation to present at that conference on how their project runs their Secure Development Life Cycle process. Don’t worry if you’re too shy to get up on stage; presenting isn’t obligatory but we really do want successful projects to share their experiences so that other projects can learn from your experiences.

On to the 10,000 projects and 1,000 badges! Woohoo!