[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.
Luc
More information about the questions
mailing list