[ntp:questions] client behind NAT (low-port bug)

[Dave Hart]

On Sun, Apr 15, 2012 at 13:08, Jason Lixfeld <jason-ntp at lixfeld.ca> wrote:
> Hi,
>
> Per
> http://groups.google.com/group/comp.protocols.time.ntp/msg/5a0f45eaecc06578
> I checked ntp_proto.c and found that in the latest 4.2.7, the same issue
> seems to persist as what David was suggesting was the underlying issue.
>
>        /*
>         * Monitor the packet and get restrictions. Note that the packet
>         * length for control and private mode packets must be checked
>         * by the service routines. Some restrictions have to be handled
>         * later in order to generate a kiss-o'-death packet.
>         */
>        /*
>         * Bogus port check is before anything, since it probably
>         * reveals a clogging attack.
>         */
>        sys_received++;
>        if (SRCPORT(&rbufp->recv_srcadr) < NTP_PORT) {
>                sys_badlength++;
>                return;                         /* bogus port */
>        }
>
>
> I'm wondering if there is another fix here?  Do I manually change
> NTP_PORT above to 0 (not being a programmer by any stretch,
> not knowing the farther reaching effects of such a change) and
> recompile?

You're right.  I'm baffled now how I managed to find code in 4.2.7
that isn't there, code I recall seeing a few days ago which allowed
anything but port 0.  I don't make claims about the code without
verifying it, so this is also embarrassing.

Please file a bug report (and sign up for an account to do so if you
haven't one already) at http://bugs.ntp.org/

To work around it, change the test above to:

        if (0 == SRCPORT(&rbufp->recv_srcadr)) {

My apology for the misinformation.

Cheers,
Dave Hart