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 3045 - Bad authentication demobilizes ephemeral associations
Summary: Bad authentication demobilizes ephemeral associations
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:47 UTC by Miroslav Lichvar
Modified: 2016-06-02 14:09 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:47:13 UTC

    
Comment 1 Harlan Stenn 2016-05-05 08:52:12 UTC
Miroslav writes:

The recent vulnerability CVE-2016-1547 was about spoofed crypto-NAKs
demobilizing ephemeral associations. There is a similar problem with
packets that don't authenticate properly. An attacker can send a
spoofed packet with random MAC which will demobilize an ephemeral
association.

It seems there is also a problem with the peer_clear() call when
autokey is enabled on permanent associations. The association is not
demobilized with a spoofed crypto-NAK or packet with bad MAC, but the
state variables are reset in the peer_clear() call, which I think
allows a DoS attack preventing synchronization using that association.
Comment 2 Harlan Stenn 2016-05-05 08:55:34 UTC
(In reply to comment #1)
> Miroslav writes:
> It seems there is also a problem with the peer_clear() call when
> autokey is enabled on permanent associations. The association is not
> demobilized with a spoofed crypto-NAK or packet with bad MAC, but the
> state variables are reset in the peer_clear() call, which I think
> allows a DoS attack preventing synchronization using that association.

Miroslav says the above (2nd paragraph) is really bug 3043.
Comment 3 Harlan Stenn 2016-05-13 09:08:14 UTC
Miroslav,

There are several things going on here, and they affect different scenarios.

One is that we're about do install additional timestamp checks in the code to prevent the bulk of the crypto-NAK forgeries.

The second goes to unpeer_digest_early.  By default, this value is enabled because under normal conditions calling unpeer() early, ie, upon receipt of a (valid) crypto-NAK is a good thing - it gets the association re-synched about 8 pool intervals sooner, and without losing those 8 polls.

If you have a machine that is not being frequently "attacked" with spoofed crypto-NAK packets, the default behavior is best.

If you have a machine that *is* being frequently successfully attacked (this attack will be more difficult starting with 4.2.8p8) then putting "disable unpeer_digest_early" is probably best.
Comment 4 Harlan Stenn 2016-05-23 09:59:52 UTC
Improved packet timestamp checks are STAGED for 4.2.8p8.