[ntp:security] [Bug 3044] Processing spoofed server packets

bugzilla-daemon at ntp.org bugzilla-daemon at ntp.org
Thu May 5 07:18:35 UTC 2016


Harlan Stenn <stenn at ntp.org> changed:

           What    |Removed                     |Added
            Summary|test #3                     |Processing spoofed server
                   |                            |packets

--- Comment #1 from Harlan Stenn <stenn at ntp.org> 2016-05-05 07:18:35 UTC ---
Miroslav writes:

I was wondering if the fact that spoofed packets that failed some of
the early NTP tests in receive() may still enter the process_packet()
function in ntp_proto.c and set some peer variables before the packet
is actually dropped should be treated as a security vulnerability.

It looks like setting some of the variables to the values from the
spoofed packet could be useful in certain attacks.

For instance, with ntpd configured with three servers I was able to
arm the leap timer by setting the leap bits of the three sources. When
a genuine packet is received and the clock is updated, the leap value
will be overwritten for that source, but the two other sources are
still able to form a majority and arm the leap timer.

I suspect disabling sources in the source selection by setting their
leap or stratum as unsychronized could be useful in some cases too.
Setting the root delay and dispersion could change the outcome of the
selection routine as well.

The impact is probably low and from the recent changes in the ntp code
it looks like the intention is to prevent spoofed packets to set the
peer variables, but I think it would be good to get a CVE for it and
fix it properly.

What do you think?

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