[ntp:security] NOEPEER patch

Martin Burnicki martin.burnicki at meinberg.de
Thu Aug 2 11:25:55 UTC 2018


Harlan,

I'm trying to find out more details on this.

Martin

Harlan Stenn wrote:
> 
> On 8/2/2018 3:35 AM, Martin Burnicki wrote:
>> Harlan,
>>
>> I'm currently running tests with the updated ntp_proto.c file you provided.
>>
>> A strange observation I've made even with the original ntp_proto.c:
>>
>> If the local ntpd receives an "symmetric active" packet signed with an
>> unknown/untrusted key, it sends a "symmetric **active**" packet with a
>> crypto NAK back to the remote node.
> 
> Yes, it looks like it has done this for Years.
> 
>> Contrarily, if a "client" request with unknown key is received, a
>> "server" reply is sent back, with a crypto NAK appended. So shouldn't
>> ntpd send a "symmetric **passive**" response with crypto NAK in this case?
>>
>> This would make more sense to me.
> 
> It makes more sense to me, too, and my thoughts are we leave the legacy
> behavior in place and change this in ntp-4.4.
> 
> I'm open to discussion about this.
> 
>> When the remote node that initially sent the "symmetric active" request
>> receives the "symmetric **active**" response with crypto NAK then it
>> also generates an error message that is IMO misleading in this case, e.g.
>>
>> Invalid-NAK error at 20
>>
>> This message is repeated after each symmetric active poll.
>>
>> This would mean that the **NAK** is invalid, but actually a valid crypto
>> NAK was received in a response simply because an unknown key has been
>> used in the request.
> 
> An invalid crypto-NAK means at least one of the following is true:
> 
> - The packet is not a SERVER, ACTIVE, or PASSIVE packet, or
> - the keyID is not 0, or
> - there is no peer association, or the peer doesn't use crypto,
>   or the peer is not using Autokey, or
> - the packet has a 0rigin, or a zero myorg, or the peer origin
>   doesn't match myorg
> 
> So one of the above must be true.  Apparently not the first 2 cases, so
> the third and/or fourth cases must be true.
> 
> If the NAK is invalid, we should not pay attention to it.  Believing an
> invalid NAK is a DoS attack.  This won't cause the packet to be
> believed, but it will prevent an otherwise valid association from being
> torn-down.
> 
> So if this is a valid NAK, we need to augment the tests above.
> 
> I'd rather not delay p12 for this.  But I will if you think it's
> important.  Would you please open a bug report on this?
> 
>> Not sure under which other conditions this log message is generated, but
>> I think we should first make sure that the response packet mode for this
>> case is changed to "symmetric **passive**". An extra log message
>> shouldn't be necessary since the "Auth not OK" should be visible in the
>> ntpq billboard, but eventually a debug message could be generated instead.
> 
> Does changing the response from ACTIVE to PASSIVE make any difference here?
> 
> If we can identify exactly why the above list of tests are wrong in this
> case, that will change this from an INVALIDNAK to a VALIDNAK.
> 
> But we have to do the right thing here.
> 
> I'm curious how this change will make a difference.  The result will
> still be that the association is being rejected because the MAC was "wrong".
> 


-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy



More information about the security mailing list