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 2936 - Skeleton Key: Any system knowing the trusted key can serve time
Summary: Skeleton Key: Any system knowing the trusted key can serve time
Status: RESOLVED FIXED
Alias: None
Product: ntp
Classification: Unclassified
Component: ntpd (show other bugs)
Version: 4.2.8
Hardware: All All
: P2 blocker
Assignee: Harlan Stenn
URL:
Depends on:
Blocks:
 
Reported: 2015-10-11 01:24 UTC by Harlan Stenn
Modified: 2016-04-27 04:04 UTC (History)
5 users (show)

See Also:
stenn: blocking4.2.8+

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Harlan Stenn 2015-10-11 01:24:06 UTC 
Symmetric key encryption requires a single trusted key to be specified for each server configuration. A key specified only for one server should only work to authenticate that server, other trusted keys should be refused.

Instead we observe that when symmetric key authentication is verified, there is no check that the key used is the key specified for the address, any trusted key can be used as long as the keyid references another key the systems share and that key is used to compute the MAC.

This has three implications for the client server model. A client that has multiple servers configured each with different keys could be attacked by one of its servers spoofing every other server using its own key. Even worse a server can be attacked by any of its authenticated clients in a similar manner.

Finally, being able to use any key to authenticate a packet for a client or server means that if any key in the trustedkeys list uses a  weak digest algorithim (MD5), then an attacker can abuse that method instead of being restricted by the stronger keys configured.

There is no clear location in the code where this defect occurs, since it exists due to an omission. Verifying the key used matches the proper server's key could be done in ntp_proto.c around line 803 (in 4.8.2p3) where authdecrypt is called, or it might make sense to build it into the libntp code such as the authdecrypt function itself.

Be aware that this issue could affect other ntpd modes of operation such as broadcast or active/passive peering.

This defect was discovered by Matt Street <mastreet@cisco.com>
Comment 1 Harlan Stenn 2015-10-11 01:30:34 UTC 
The first and biggest problem I see with this report is that it assumes there is supposed to be a connection between a private key and a server.  No such connection exists with symmetric keys for NTP.
Comment 2 Danny Mayer 2015-10-13 01:35:07 UTC 
I think that there may be a problem here. Once an association has been authenticated then that packets between the two systems need to continue to use the key used for creating that association trust. What needs to happen is that when the trust is established a reference to the key used should be kept until the association is cleared. Otherwise, according to the report, any other valid key in the list can be used, probably by a rogue server that has a trusted key which can spoof the packets.
Comment 3 Juergen Perlinger 2015-10-28 05:52:14 UTC 
Danny and Harlan, you have both a point there.

'Hijacking' a key that is used for another peer is only possible if a key is already compromised.

Hijacking after authentication can be prevented by keeping the (auto-)key in the peer structure once a peer authenticated itself with it. Packets that need cryptographic authentication are validated against this key and ignored otherwise. (This must be of course 'forgotten' when the peer association drops.)

Alas, this does not prevent *establishing* a peer connection from a rogue peer under false identity. To prevent *this*, we need an association between IP addresses and the allowed keys for an address, and such does not exist yet.

The first issue should not be too hard to tackle, but it doesn't get us very far without solving the second one.

The options we have here is either another key format that includes addresses associated with the key (which is IMHO a massive compatibility problem) or an additional config file that provides that associations. The additional config data takes a bit more effort to maintain, but it might be more secure and provide a better migration path.

An additional step could 'quarantine' key material that has been found to be used in fraudulent ways, e.g. by moving it into another directory (so it cannot be used again) and dropping the autokey from the key store.

Am I missing something vital here, or would implementing these 3 steps solve the issue?
Comment 4 Harlan Stenn 2016-01-06 11:34:54 UTC 
(In reply to comment #2)
> I think that there may be a problem here. Once an association has been
> authenticated then that packets between the two systems need to continue to use
> the key used for creating that association trust. What needs to happen is that
> when the trust is established a reference to the key used should be kept until
> the association is cleared. Otherwise, according to the report, any other valid
> key in the list can be used, probably by a rogue server that has a trusted key
> which can spoof the packets.

Danny, please say more.  There's nothing wrong with there being multiple trusted keys, and since we're talking about UDP here, we have no way of knowing if a client starts talking to a server with "trusted key #1" and then the client gets reconfigured/restarting using "trusted key #2".  There's no reason this should not work.

What exactly do you mean by an "association" here?

I can still see it being a reasonable conclusion that this report is not a valid bug.
Comment 5 Harlan Stenn 2016-01-15 10:26:57 UTC 
Thinking about implementing:

 trustedkey <keyid> ... [ from <ip> ...]

for a first pass at a solution.
Comment 6 Harlan Stenn 2016-01-20 12:14:26 UTC 
Resolved in 4.2.8p6 and 4.3.90.
Comment 7 Harlan Stenn 2016-01-21 23:08:46 UTC 
The solution is to have the ntp.keys file contain an optional 4th column, a comma-separated list of IPs that are allowed to serve time.

This is documented in the ntp.keys documentation.  We still need to update html/authentic.html - see bug 2997.
Comment 8 Harlan Stenn 2016-01-23 10:25:12 UTC 
ACTIVE was fixed - PASSIVE was not.
Comment 9 Harlan Stenn 2016-01-23 10:34:58 UTC 
STAGED for p7.