[ntp:security] [Bug 3415] test1
bugzilla-daemon at ntp.org
bugzilla-daemon at ntp.org
Sun Oct 8 10:16:50 UTC 2017
Harlan Stenn <stenn at ntp.org> changed:
What |Removed |Added
--- Comment #1 from Harlan Stenn <stenn at ntp.org> 2017-07-06 10:44:26 UTC ---
on 13 Mar 2017 Miroslav emailed us, writing:
there was a security issue reported on the ntp questions list
recently. It allows clients that have a key to create symmetric
associations with the server. The problem is that the nopeer
restriction applies only to unauthenticated packets, i.e. it's
effective only when authentication is disabled with "disable auth".
This works as documented, but it is a major problem for services
that give keys to untrusted clients, like NIST does for instance.
I replied, asking:
> Is this issue solved by using the optional IP list in the ntp.keys file?
No, not really. Even if the server restricted each key to one IP
address, the attacker could ask for multiple keys and still create
multiple symmetric associations, which would outvote the good time
> Or was that something else?
I think that was a different issue, where an attacker could create
spoofed responses using a different key than the peer/client was
In this case it's about preventing clients from creating a symmetric
association with the key they got. I think the best fix would be to
change the nopeer option to apply to all packets. I think that's what
most people expect it to be doing. Would you agree?
H: I'll talk with Dave Mills about this. While I agree with you, Dave
expressly implemented and documented this behavior and I'd like to
understand why, with costs/benefits.
M: Thanks, Harlan. The other possibilities include a new restrict option,
allowing clients (and only clients) to use keys that are not marked as
trusted, or a global flag that would disable all ephemeral
On Tue, Jun 06, 2017 at 02:44:19AM -0700, Harlan Stenn wrote:
> On 6/6/17 1:21 AM, Miroslav Lichvar wrote:
>> I think it's a serious security issue, which is already public. It
>> seems not even the extended key file format, allowing only one IP
>> address per key, can prevent the attack. With one IP address it's
>> still possible to create a large number of passive associations with
>> the server and take control of its clock.
>> Should we assign a CVE?
> Maybe. But before we do this:
> - Do you have suggestions on how to fix this?
I think there are two separate issues.
One is that there is no way for an admin of an NTP server to give
someone a key for authenticating server responses and at the same time
not allow peering with that server. One possible fix is to change the
the nopeer restrict option to apply to all packets, not just
unauthenticated. Another fix would be to allow marking keys in the key
file as "client only". Such keys could be used for authentication, but
they couldn't create a new associations.
The other issue is that when someone has a key and is allowed to make
a symmetric association, they can create multiple associations (even
from a single IP address) in order to outvote other time sources and
effectively take control of the server's clock. This could be fixed
with a new option that would limit the number of associations per key.
If set to one association per key, a single key can create only one
association, which is not enough to outvote other sources.
Configure bugmail: https://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