[ntp:security] [Bug 3020] Refclock impersonation vulnerability

bugzilla-daemon at ntp.org bugzilla-daemon at ntp.org
Fri Feb 12 09:03:31 UTC 2016


Harlan Stenn <stenn at ntp.org> changed:

           What    |Removed                     |Added
           Priority|P5                          |P3
              Group|                            |Security
                 CC|                            |mvangund at cisco.com
            Summary|x                           |Refclock impersonation
                   |                            |vulnerability
              Flags|                            |blocking4.2.8+

--- Comment #1 from Harlan Stenn <stenn at ntp.org> 2016-02-12 09:03:31 UTC ---
ntpd relies on the underlying operating system to protect it from requests that
impersonate refclocks.  Because refclocks are treated like other peers and
stored in the same structure, any packet with a source ip address of a refclock
( for example) that reaches the receive() function will match that
refclock's peer record and will be treated as a trusted peer.

Any system that lacks the typical martian packet filtering which would block
these packets is in danger of having its time controlled by an attacker. The
read_network_packet() function in ntp_io.c addresses this issue for IPv6 with
Bug 2672, because some OS's were known to not block spoofed ::1 addresses.

Some, if not all, refclock drivers set their origin values to zero. It would be
trivial to control time on a system with one of these drivers configured if
these spoofed packets were not filtered.

ntpd should filter IPv4 packets with the address of 127.127.x.x for proactive
protection for systems that fail to implement martian packet filtering.


Configure bugmail: http://bugs.ntp.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

More information about the security mailing list