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.8p15
was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.
Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
See LockingNtpdInMemoryDev for discussion of this topic.
6.9. Locking ntpd in memory
Related Topics: NtpdProcessResidencyIssues,
Bug #387
Currently,
ntpd
will lock itself in memory if the appropriate system calls are available.
This is generally good because it means
ntpd
can quickly respond to time updates.
ntp-4.2.6
and earlier
For some OSes, the amount of locked memory is currently hardcoded in
ntpd.c
.
This is Suboptimal.
- AIX: reserve 32k of extra stack space (less 8 4k pages).
- WINNT callls
SetProcessWorkingSetSize()
and VirtualLock()
, at about 4MB(?).
- Systems that use
setrlimit()
and mlockall()
seem to reserve an extra 50 4k pages.
- this seems to be too much for some *BSD systems, and not enough for some linux systems.
If the
ntp.conf
file contains
rlimit memlock 0
then while memory will be locked, there will be no limit to how much memory is locked. This behavior is OS-specific. Some will only lock what is needed, some will lock current memory. Sometimes more memory is needed and this may or may not be allowed. But this needs to be re-examined and better documented, as there is code in
ntpd.c
for
rlimit
and then later, when
ntp_config()
is called, we get a value for
do_memlock
.
ntp-4.2.8
If the
ntp.conf
file contains
rlimit memlock -1
then
ntpd
does not call
mlockall()
.
If the
ntp.conf
fole contains
rlimit memlock 0
then the previous behavior is done -
mlockall()
is called but
rlimit()
is not.