NTP Bug 2947

ntpq protocol vulnerable to replay attacks

  • Date Resolved: Stable (4.2.8p7) XX Feb 2016; Dev (4.3.XX) XX Feb 2016
  • References: Sec 2547 / CVE-2015-8140
  • Affects: All ntp-4 releases up to, but not including 4.2.8p6, and 4.3.0 up to, but not including 4.3.XX
  • CVSS2: (AV:A/AC:M/Au:N/C:P/I:P/A:P) Base Score: 5.4 - MEDIUM
  • CVSS3: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N) Base Score: 5.3 - MEDIUM
  • Summary: The ntpq protocol is vulnerable to replay attacks. The sequence number being included under the signature fails to prevent replay attacks for two reasons. Commands that don't require authentication can be used to move the sequence number forward, and NTP doesn't actually care what sequence number is used so a packet can be replayed at any time. If, for example, an attacker can intercept authenticated reconfiguration commands that would. for example, tell ntpd to connect with a server that turns out to be malicious and a subsequent reconfiguration directive removed that malicious server, the attacker could replay the configuration command to re-establish an association to malicious server. Yes, this is an unlikely scenario, but it could still happen.
  • Mitigation:
    • Configure ntpd to get time from multiple sources.
    • Use restrict statments in your ntp.conf file to limit who is allowed to issue ntpq queries and remote configuration commands.
    • Monitor your ntpd instances.
  • Credit: This weakness was discovered by Matt Street of Cisco ASIG.

This topic: Main > SecurityNotice > NtpBug2947
Topic revision: r2 - 2016-02-12 - 06:22:25 - HarlanStenn
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback