[ntp:questions] Re: "Listen on" semantics
mayer at ntp.isc.org
Tue Sep 19 12:34:18 UTC 2006
Luc Pardon wrote:
> Danny Mayer wrote:
>> 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.
At which point your log timestamps better be accurate so you can trace
things back. This is *NOT* from a developer's viewpoint.
> 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.
No, there *ARE* bugs in the code, that's not even speculation, but
that's not in any way related to the question at hand.
> 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.
No, the code actual spends a lot of time checking the packet that comes
in before it uses the contents. malformed packets will be immediately
rejected. The only other thing you can do to an NTP packet is put in bad
timestamps, which if it is incoming to a client will be dismissed as way
out of range. The only other parts in an NTP packet deals with security
but you won't get far with that.
Are there other ways of doing something nasty to a packet? Undoubtedly
there are things we haven't thought of but there's not a lot in the
packet that you can change in the first place. None of this has anything
to do with binding to all interface addresses.
> 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.
Very true, but what has this to do with binding to all interface addresses?
> 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.
This does you no good, either way. The *ONLY* solution here is to use
the restrict processing since you *MUST* accept packets on both NIC's.
This is even if we had the ability to allow you to select which
interface addressess to bind to you'd still have the same problem.
If you are suggesting that you want to run two copies of ntpd on your
server then you have a bigger problem since ntpd is not designed to work
that way and it would be hard to support such a situation.
> In any case, the simple fact is: as soon as you accept packets, you
> are posing a security risk.
Well the alternative to that is not to connect to anything.
> 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.
You have that option today by modifying the code to your liking. Not the
answer you want but it's even more fraught with potential security
issues that I wouldn't want to support such a configuration.
>> My two shillings worth.
>>> Just my 0.02 Euro.
> At the current exchange rate, that gives your's more weight than mine
> As far as I am concerned, we can leave it at that, and agree to
> disagree. I won't have an issue with that.
Well this is an important discussion. Mine is only one opinion. Others
on the project have their own opinions.
More information about the questions