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.8p13 was released on 07 March 2019. It addresses 1 medium-severity security issue in ntpd, and provides 17 non-security bugfixes and 1 other improvements over 4.2.8p12.

Please see the NTP Security Notice for vulnerability and mitigation details.

---

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

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.