[ntp:questions] Re: "Listen on" semantics

Luc Pardon xntp at skopos.be
Fri Sep 15 09:08:17 UTC 2006

Danny Mayer wrote:

 > ...
> What -I really does is specify to ONLY accept those packets
> that arrive on that specific interface and it drops all packets arriving
> on all other interface. It's still listening on those addresses.
> ...

     OK, thanks for the explanation. It's much clearer now.

> By binding to all interfaces and addresses we
> prevent other applications using them. The worst thing you can have is
> two different applications modifying the clock.

    This is, I think, where we have fundamentally different perspectives.

    To you, the worst thing may well be a screwed-up clock (and 
incidentally that's a perfect mindset for a clock-daemon developer <g>). 
To me as an administrator, however, the Worst Thing is having the box 
hacked and rooted.

    Your reasoning makes sense, but you are reasoning from the 
assumption that there are no bugs in the code. Nobody can guarantee 
that, and certainly not an application with +73k lines of code (wc -l 
ntp-dev-4.2.3p39/ntpd/*.c). That's simply impossible.

    Your reasoning also assumes that every incoming packet is playing by 
the rules, or at least that the code can handle all kinds of malformed 
packets, that it will never cut its virtual fingers on the sharp edges 
of packets that were crafted on purpose by malicious minds. That is a 
dangerous assumption in today's world.

    Yes, the code path may be much shorter if you drop the packets right 
away. But it takes only one typo to create an exploitable vulnerability. 
If not today, then maybe tomorrow, after the next maintenance cycle.

    Besides, the -I switch won't help me with the most vulnerable 
interface on a two-NIC box acting as a stratum 3 time server for an 
internal network. I tried to disable the public interface (by specifying 
-I <internal interface>) but then it can't seem to reach the stratum 2 
servers outside. The net result is that I have no choice but to let any 
"packet from hell" make its way through the "restrict" processing.

    In any case, the simple fact is: as soon as you accept packets, you 
are posing a security risk.

    Of course you are right that, if I run two different applications 
that modify the clock, I may have a problem, but at least it's a problem 
of my own making. If you really want to protect me from shooting myself 
in the foot by locking all unused interfaces, make it optional. Make it 
the default if you want, but at least give me the option to disable it.

> My two shillings worth.
> Danny
>>    Just my 0.02 Euro.
>>    Luc
    At the current exchange rate, that gives your's more weight than 
mine <g>.

    As far as I am concerned, we can leave it at that, and agree to 
disagree. I won't have an issue with that.


More information about the questions mailing list