[ntp:hackers] Why are we going down this road? Question on listen-on, query-on, -I

Danny Mayer mayer at ntp.org
Mon Jun 8 02:42:41 UTC 2009


Brian Utterback wrote:
> Danny, your arguments are not very convincing.
> 
>> No, that's not the only issue. The security is a bigger issue
>> and the need to ensure that one and only one application is
>> updating and discipling the system clock.
> 
> The security issue is a complete red herring. First, binding all the
> addresses does not "ensure that one and only one application is updating
> and discipling the system clock", it only ensures that only one program
> is bound to that port, which is not the same thing.
> 
> If you are trying to prevent a malicious attempts to hijack the port,
> then binding all the addresses doesn't help if interfaces are ever
> added, since there is still a window of opportunity for the malicious
> program to bind the address.
> 
> On Windows, as you noted SO_EXCLUSIVEADDRUSE will probably deal with
> that issue nicely, but therefore on Windows you don't need to bind all
> the addresses for security reasons.
> 
> As you noted most Unixen do not have this option (Open Solaris has the
> equivalent SO_EXCLBIND, by the way).

We should add that option then in the same way as dave did for Windows.

 But then, Unixen have the root
> privilege model. So, to hijack port 123, would require a local process
> running as root. If you have a malicious local program running as root,
> then you have a bigger problem, and binding all the addresses is not
> going to do you any good.

I'm not saying that the Unix root privilege model is the best, but it is
what it is.

> 
> The bottom line is that to deal with the security issue on Windows does
> not require binding all addresses because of SO_EXCLUSIVEADDRUSE, and on
> Unix-like systems the root privilege requirement likewise does not
> require it. Most embedded types of OS's would not be vulnerable because
> of the difficulty of having a malicious local process. Not to mention,
> has there ever been a report of malicious NTP port hijacking?   My guess
> is no.

We try very hard to prevent buffer overflow attack locations but the
fact is that any system that runs an application as root is vunerable to
attacks through such buffer overflows.

  I don't know of any other service that binds all the addresses
> for this reason, do you?
> 

No many applications require limiting what can mess with a particular
part of the system, in this case the clock. If you can mess with the
clock then you can cause all sorts of havoc, including causing failure
with kerberos, certifications, ipsec, and all sorts of other
applications including db servers.

>> Of course that program uses sendmsg()/recvmsg() which is not
>> implemented on older versions of various operating systems.
>> As long as we are committed to supporting older versions of
>> operating systems we cannot use them.
> 
> Maybe. This is a legitimate concern. However, do we really have any idea
> which operating systems do not have sendmsg and recvmsg? Are we really
> committed to supporting legacy systems on all versions of NTP forever?
> Couldn't we just say as of NTP 4.x.x, you must have a POSIX compliant
> sendmsg and recvmsg? Maybe, maybe not. If not, then couldn't we deal
> with the issue by moving the "bind-all-interfaces" code to it's own
> source file and (as Terje says) tell them that they are limited to less
> than 1000 interfaces? Can't we plan for the day that the
> bind-all-interfaces code can go away instead of making it a permanent
> fixture of NTP?

No.

> 
>> policy on what they want NTP to do. Your solution also actually
>> requires that NTP accept queries on all of those 1000+ IP
>> addresses, even if the operator does not want that. So even
>> if we use sendmsg()/recvmsg() you are still not giving the
>> adminstrator the tools needed to limit what address they want
>> their users to use for NTP requests.
> 
> So what? Why should we provide that capability? Very few other network
> services provide it. The proper place for firewall functions is in the
> firewall. If they have to do this, then use packet filters.
> 

You are assuming that there is a firewall in between. Some of the
requestors are inside the firewall. Some others are outside a firewall.
You can always add firewalls but you need to know how to do that right.

>> BIND9 uses the wildcard address for IPv6 but you can limit what
>> it will listen on using the listen-on and listen-on-v6
>> directives. It also allows a query-source directive.
> 
> As I said, I like query-on just fine. I would argue that BIND has a more
> legitimate need to monitor network topology. 

BIND9's monitoring of network topology is limited to finding the most
responsive authorative nameserver and occasionally rechecking.

> Also, I am not totally
> opposed to having listen-on as such, although I am unconvinced of the
> need. I just think we have gone way, way overboard in the complexity for
> the simple case.

No. Actually the code is very simple and did not take much work to
implement.

 If there is no listen-on and query-on, there should be
> two sockets bound. Add one more for the query-on. Subtract 2 and add 1
> for each listen-on if you must. But no routing sockets, no iterations
> over the interface list. Oh and by the way, what does having "listen-on"
> do to your argument to security?

Your suggestion gives you nothing in the way of security

> 
>> NFS I find totally bizarre for using UDP instead of TCP since for a
>> network file system you want reliability so why use an unreliable
>> protocol in the first place.
> 
> I find this a very ironic statement since we are talking about NTP and
> NTP uses UDP. I guess you think that NTP is unreliable, huh? NFS used
> UDP for the same reason NTP does, UDP provides the characteristics it
> needs. NFS implements the reliability features at the session layer
> instead of the transport layer, that's all.
> 

NTP is designed to for unreliability. If you lose an NTP packet, then
NTP does not care. It waits for the results of the next one. NFS on the
other hand needs to ensure that the packets gets delivered otherwise you
lose the contents of the file. This is what TCP was designed for. Moving
that to the session layer does not make a lot of sense.

>> We need to introduce these things because people do strange
>> things to their networks and we somehow need to be able to
>> support them.
> 
> Maybe. The only "strange thing" in the network you have mentioned in
> this argument is having thousands of IP addresses on one system. And
> binding the wildcard addresses addresses (heh) that issue much better
> than binding them all individually. Of course, there is the issue of
> having dynamically changing addresses like on load balancers and
> laptops, where the wildcard address solution also works much better.
> 
>> Most protocols, not just NTP, require that the server
>> replies using the same address as the request was sent to,
>> otherwise the reply won't be recognized as a reply.
> 
> Really? Name one.

Every one.

> Of course, all TCP protocols trivially have this requirement, so they
> don't count. DNS has this requirement, but as Paul Vixie told me, this
> is because the query-id would only allow 64K outstanding transactions,
> and that is not enough for many systems.
> 
Not exactly. It's much more complicated than that and spoofing them is
easy as Kaminsky has shown which is why all of the major DNS providers
last year suddenly had to introduce random outgoing port numbers making
it hard to predict.

> Any service built on top of RPC does not have this requirement. Because
> RFC 1123 made this a SHOULD, rather than a MUST, most UDP protocols were
> designed to work with hosts that did not adhere to it.
> 
> This is neither here nor there though, since I have already conceded
> that the response must match the request, for NTP if not for all things
> UDP. But I think it would have been cool to use the trans/org timestamp
> as a transaction id. And I bet even autokey could have been designed
> without this requirement, had it been a consideration at the time. But
> that ship has sailed.
> 

The original transmit NTP timestamp *is* the nonce along with the ip
address /port number.

Danny

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



More information about the hackers mailing list