[ntp:security] NOEPEER patch

juergen perlinger juergen.perlinger at t-online.de
Sat Aug 4 05:24:19 UTC 2018


Hey all,


On 08/03/2018 08:51 PM, Harlan Stenn wrote:
> It’s a good change, I think. Instead of bailing early saying it’s good, we bail early when we know it’s bad, and only say it’s good at the very end, when no problems are found. 

It actually happened as fix for SEC3043, where an arbitrary CRYPTO-NAK
could be used to disrupt an association. (Side channel attack)

On a different note, FreeNode seems to be down. At least I cannot
register my nicks, and NTP/NTP-DEV are restricted channels.

Any ideas how to communicate?

> 
> Sent from my iPhone. Please excuse brevity and typos.
> 
>> On Aug 3, 2018, at 11:20 AM, juergen perlinger <juergen.perlinger at t-online.de> wrote:
>>
>> Hello Harlan, hello Martin,
>>
>>> On 08/03/2018 05:28 PM, Martin Burnicki wrote:
>>> Harlan,
>>>
>>> Harlan Stenn wrote:
>>>> Before Pearly's change, the code was:
>>>>
>>>>  if (   peer
>>>>      && (peer->keyid > 0 || peer->flags & FLAG_SKEY))
>>>>    return VALIDNAK;
>>>>
>>>> and now it is:
>>>>
>>>>  if (!peer || !peer->keyid || !(peer->flags & FLAG_SKEY)
>>>>    return INVALIDNAK;
>>>>
>>>> and I think we want:
>>>>
>>>>  if (!peer || (!peer->keyid && !(peer->flags & FLAG_SKEY))
>>>>    return INVALIDNAK;
>>>>
>>>> or:
>>>>
>>>>  if (!peer || !(peer->keyid || (peer->flags & FLAG_SKEY))
>>>>    return INVALIDNAK;
>>>
>>> This makes sense to me. Pearly's change has also changed the behavior.
>>
>> Seems I messed it up somewhere in time. I'll check tomorrow when & why I
>> made that change... right now it's too hot to think clearly...
>>
>>>
>>> I've now changed this code section to
>>>
>>>    /*
>>>     * During the first few packets of the autokey dance there may
>>>     * not (yet) be a keyid, but in this case FLAG_SKEY is set.
>>>     * So the NAK is invalid if either there's no peer, or
>>>     * if the keyid is 0 and FLAG_SKEY is not set.
>>>     */
>>>    if (!peer || (!peer->keyid && !(peer->flags & FLAG_SKEY))) {
>>>        return INVALIDNAK;
>>>    }
>>>
>>> as you proposed, which restores the behavior of the original code.
>>>
>>> I didn't find the time today to test all variations, but with this patch
>>>
>>> - Peering works with a valid symmetric key.
>>>
>>> - If an unknown key is used then "ntpq -c as" reports "auth bad" as
>>> expected, but there are no nasty "Invalid-NAK" messages that were
>>> previously sent to the syslog after each poll.
>>>
>>> So I think this is a good solution. More tests to come.
>>>
>>>
>>> Martin
>>>
>>
>>
> 
> 



More information about the security mailing list