NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.
ntp-4.2.8p12
was released on 14 August 2018. It addresses 1 low-/medium-severity security issue in ntpd, 1 low-severity security issue in ntpq and ntpdc, and provides 27 non-security bugfixes and 4 other improvements over 4.2.8p11.
Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
Loadable Refclock Drivers
ntpd
has traditionally used statically-linked reference clock drivers. While this means that the executable is more tamper-proof, it also means the size and functionality of the executable is determined at compile-time.
Dave Mills wants to limit the addition of new drivers to the distribution as many consider the current fully-configured executable to be "too big".
Harlan believes that there are some potential problems with traditional loadable modules:
- they are an easy way to "infect" a system, especially if
ntpd
is running as root.
- the codebase is currently extremely portable, even to fairly old hardware and OSes. There are still a very useful number of systems that do not support
dlopen()
and friends.
Harlan further believes that it should be possible to provide a lightweight "refclock processing language" that would provide a relatively safe way to interface with a reference clock, perform the required manipulation of the data, and send the results to
refclock_process()
and friends.
Since Harlan is also fond of saying that there needs to be "sufficient" mechanism to provide the needed functionality, and that mechanism should be sufficiently robust to support a variety of different policy choices, the following is proposed.
Ways to provide refclock drivers
- static
- native refclock driver executables
- API to a refclock processing language
- dynamically loaded
- native refclock driver executables
- API to a refclock processing language
The API to a refclock processing language could include:
- forth
- lisp
- java
- python
- tcl
just to name a few.
Related Topics: http://sourceware.org/libffi/
Please edit above or comment below, as appropriate.
--
HarlanStenn - 01 Jul 2005
It is correct that there is an increased risk when using dloaded modules. So the modules should be
picked up from a fixed or configured directory, not via LD_LIRARY_PATH. This reduces the risk somewhat.
Additionally a permission sanitiy check such as in sendmail for accessing trusted files could be used.
As for portability I read the
ltdl
documentation and the libtool support from the GNU autoconfig
suite. Currently I have the impression that these tools could help around the concerns about
portability mentioned above. On platforms which don't support dloading it will statically link the required
files.
ltdl
is an abstraction from the actual dloading mechanism and seems to be a way to keep the
code from being infected with the portability-#ifdef disease.
The idea of using a well known scripting langugage looks charming at first. But I think there are some
drawbacks:
- only forth, lisp stand a chance of having a reasonably small interpreter footprint
- python, java, tcl are bigger citizens.
- The (memory) resource model of scripting languages may be not appropriate for a long running daemon.
- Mechanisms such as garbage collection are not suitable for a near real time application. This is especially problemetatic as
GC
usually happens at the most inconvienient time. Given that and that ntpd has SIGIO blocked during refclock/protocol processing we might be incuring significant and uncontrollable delays during ntpd operation.
- (dynamic) memory usage should be kept to a minimum. The current drivers are faily reasonable in that respect
- Almost all scripting languages would need to be extended by an API to access internals of the NTP core engine. There are quite a few variables that refclock_drivers like to twiddle with.
- If we use a scripting language we would also need to re-implement and re-validate the refclocks.
- With a scripting language we also import a maintenance risk as we would have to track the scripting implementation for bug and security fixes.
Seeing the list above I get the impression that trying to use
ltdl
with the current native refclocks
is quite a bit less work and risk and it preserves the current value of the refclocks. Converting the current
refclocks to dloadable ones is a fairly straighforward process, especially if
ltdl
lives up to its promises.
Comment ? More ideas ?
--
FrankKardel - 01 Jul 2005
My point about many different potential scripting languages was that once we supported one scripting language the mechanism would be in place to support others. The choice of which ones to use (or not) would become a policy choice. It would also be much easier to test and compare different scripting languages.
As for the
GC
issues, I wonder if we could use the
SHM
refclock to solve this issue. In this case the actual refclock code would be running in a different process and the information would simply be passed to
ntpd
via the
shm
interface.
--
HarlanStenn - 01 Jul 2005
At least for the critical part of timestamping clock messages I am not too certain that scripting languages
with possible
GC
risks are suitable for that. Processing the data formats is not so complicated that we could
benefit from the advantages of the scripting languages. And we would need some good interfaces for
tty setup, precision time stamping (clock_gettime() at minimum) and possibly
SHM
access. Not all
scripting languages fill that bill easily. Java 1.4 for example gives you just milli second resolution. This
would not be usable for us. Java 1.5 is better in that respect.
Running an additional process will get us some protection of the main daemon, but at the expense of shm resources,
additional task switches, possible re-implementation of existing concepts (io, filtering, conversion come to mind
right now) and loss of functionality unless we seriously vamp up the
SHM
interface including but not limited
to bidirectional communication if we are keeping up the practice of configuration via mode 7 messages.
--
FrankKardel - 01 Jul 2005
One of the provided "functions" should be PPSAPI support, that should include serial number checking. If we detect that the device does not properly implement serial numbers, we should squawk (once) and then continue with a full timestamp check to catch duplicated samples.
--
HarlanStenn - 2011-03-17