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.8p18 was released on 25 May 2024 and addresses 40 bugs and provides 40 improvements.

Please see the NTP 4.2.8p18 Changelog for details.

Bug 3044 - Processing spoofed server packets
Summary: Processing spoofed server packets
Status: RESOLVED FIXED
Alias: None
Product: ntp
Classification: Unclassified
Component: ntpd (show other bugs)
Version: 4.2.8
Hardware: PC All
: P3 normal
Assignee: Harlan Stenn
URL:
Depends on:
Blocks:
 
Reported: 2016-05-04 09:46 UTC by Miroslav Lichvar
Modified: 2016-06-03 05:12 UTC (History)
3 users (show)

See Also:
stenn: blocking4.2.8+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Miroslav Lichvar 2016-05-04 09:46:32 UTC

    
Comment 1 Harlan Stenn 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?
Comment 2 Harlan Stenn 2016-05-23 09:58:15 UTC
process_packet() still needs a bit of work.  We expect to call it even if the packet format checks have some known problems.

There are also situations where we (think we) want to update some peer time variables even if the packet has problems.  This has been part of ongoing discussions between me and Dave.  But it's clear we don't want to update other variables until we're sure that any provided authentication is valid.
Comment 3 Harlan Stenn 2016-05-24 12:15:12 UTC
STAGED for 4.2.8p8
Comment 4 Daniel Franke 2016-06-02 18:14:58 UTC
The security advisory for this bug references "An attacker who is able to spoof packets with *correct* origin timestamps" (emphasis added). Was that what you intended? It appears to me that the reason for this issue is that *incorrect* origin timestamps can slip through. In particular, receive() sets TEST3 when the origin timestamp is zero and TEST2 when the origin timestamp is nonzero-but-bogus, but the first place these bits necessarily abort further handling is in process_packet().
Comment 5 Miroslav Lichvar 2016-06-03 05:12:14 UTC
Yes, "spoofed packets" are packets that have wrong origin timestamp. The attacker doesn't need to know the origin timestamp, it's not a MITM attack. The descriptions of the other recently published vulnerabilities have a similar problem.