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 3043 - Autokey association reset
Summary: Autokey association reset
Status: RESOLVED FIXED
Alias: None
Product: ntp
Classification: Unclassified
Component: ntpd (show other bugs)
Version: 4.2.8
Hardware: PC All
: P3 major
Assignee: Harlan Stenn
URL:
Depends on:
Blocks:
 
Reported: 2016-05-04 09:45 UTC by Miroslav Lichvar
Modified: 2016-06-02 12:47 UTC (History)
4 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:45:50 UTC

    
Comment 1 Miroslav Lichvar 2016-05-05 12:45:02 UTC
When a permanent NTP association is configured with autokey and a packet with crypto-NAK or bad auth is received, the peer_clear() function is called to reset autokey and other variables of the association. An attacker could periodically send to the client spoofed crypto-NAKs or packets with bad MAC and prevent synchronization of the client with the source.

Before calling peer_clear() the client should check if the origin timestamp is valid and ignore spoofed packets.

I'm not sure if this is the only DoS attack on autokey or if it's worth fixing, considering autokey is insecure.
Comment 2 Juergen Perlinger 2016-05-06 18:24:25 UTC
As I discussed with Harlan for some time, CRYPTO_NAK is a design bug. It is not authenticated and therefore totally untrustworthy. The only sane decision is to completely disregard any CRYPTO_NAK packages.

The same essentially holds for all packets where MAC authentication fails. These should be IMHO summarily ignored.

Checking the origin time stamp might avoid some attacks by creating a small time window (instead of one of unlimited size) but it is still possible for an attacker to send a forged CRYPTO_NAK soon enough (before the real server replies) to run a successful attack.

I'm admittedly not deep enough into this, but I have gathered the impression that ignoring packages with bad authentication and CRYPTO_NAKs in general is the only way to go. Just my 5c, though, and I want some more votes on that before I start to butcher the code.

This would essentially cure bug 3044 and bug 3045, too. I'm just not sure what it would break.
Comment 3 Harlan Stenn 2016-05-07 09:22:14 UTC
In a separate email, Miroslav wrote:

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 4 Miroslav Lichvar 2016-05-09 07:40:40 UTC
Removing support for crypto-NAK will break autokey.

This bug is about crypto-NAKs (and packets with bad auth in general) sent by an off-path attacker, who doesn't see the traffic from the client, making the peer_clear() call. The client just needs to check if the packet is a reply to its request, i.e. the origin timestamp matches the transmit timestamp, before calling peer_clear().
Comment 5 Harlan Stenn 2016-05-23 09:33:07 UTC
(In reply to comment #2)
> As I discussed with Harlan for some time, CRYPTO_NAK is a design bug. It is not
> authenticated and therefore totally untrustworthy. The only sane decision is to
> completely disregard any CRYPTO_NAK packages.
> 
> The same essentially holds for all packets where MAC authentication fails.
> These should be IMHO summarily ignored.
> 
> Checking the origin time stamp might avoid some attacks by creating a small
> time window (instead of one of unlimited size) but it is still possible for an
> attacker to send a forged CRYPTO_NAK soon enough (before the real server
> replies) to run a successful attack.
> 
> I'm admittedly not deep enough into this, but I have gathered the impression
> that ignoring packages with bad authentication and CRYPTO_NAKs in general is
> the only way to go. Just my 5c, though, and I want some more votes on that
> before I start to butcher the code.
> 
> This would essentially cure bug 3044 and bug 3045, too. I'm just not sure what
> it would break.

By definition, a crypto-nak cannot be reliably authenticated.  Its primary purpose is to speed up a resynch in the case a key has expired.  The pros/cons of the crypto-nak should certainly be discussed, however.
Comment 6 Harlan Stenn 2016-05-23 09:54:16 UTC
Added the peer_clear_digest_early option.

STAGED for 4.2.8p8.