[ntp:security] NOEPEER patch

Martin Burnicki martin.burnicki at meinberg.de
Fri Aug 3 07:51:58 UTC 2018


Harlan Stenn wrote:
> OK, I had a talk with Dave today.
> 
> This gets more fascinating to me, and more intricate.
> 
> First, Dave says that the response to a symmetric mode request should
> always be a symmetric mode response.  No big surprise here, but I was
> thinking about some aspects of the windows client thing.

I fully agree with Dave.

> Next, we talked about crypto-NAKs.
> 
> If a valid crypto-NAK is received, it really doesn't matter:
> 
> - what mode it is (although it should be appropriate to the request)
> - what ANY of the content values are (LI bits, timestamps, etc,
>   other than the stamps to show it is a valid response packet)
> 
> because EVERY client that receives a valid crypto-NAK should squawk and
> then drop the packet.  There is NO CASE where the crypto-NAK packet
> should be expected to contain valid response data.

OK, that's basically what happens.

> So we're back to:
> 
> - why did a crypto-NAK get sent?

Because the request was sent with an unknown/invalid **symmetric** key
in this case.

> - why did the receiving system think the crypto-NAK was invalid?

I've had a look at the valid_NAK() function in ntp_proto.c.

There's a code section that originally reads:

  /*
   * Only valid if peer uses a key
   */
  if (!peer || !peer->keyid || !(peer->flags & FLAG_SKEY)) {
    return INVALIDNAK;
  }

However, according to the comment near the the definition of FLAG_SKEY
in ntp.h

#define	FLAG_SKEY	0x0800  /* autokey authentication */

FLAG_SKEY is only set in case of autokey, and it's actually not set in
this case where a packet has been received with an unknown/invalid
**symmetric** key.

After I've removed the FLAG_SKEY check in the code above, these
misleading error messages disappear, but in the output of e.g. "ntpq -c
as" the peer association is still listed with "auth" set to "bad", as
expected.

bk annotate says the FLAG_SKEY check has been introduced by Pearly,
probably with autokey in mind. Pearly, do you think it's OK to remove
this check, like I did?

I've copied my version of ntp_proto.c to my home dir on psp-deb1. You
can find the change if you search for TODO, but this still needs
cleanup: some lines I've commented out should be removed.


Beside this I've changed a single other line in that file so that now a
symmetric **passive** response with crypto NAK is sent if a symmetric
**active** request with invalid/unknown symmetric key is sent.

You see the changes if you make a diff over the ntp_proto.c files in
Harlan's and my own home dir.

The initial tests I've made show that this works as expected now, and
the strange error messages don't appear anymore.

I hope I can do and finish a complete test over the different cases
today, and will send you the test results.


Martin
-- 
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