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

Brian Utterback brian.utterback at sun.com
Mon Jun 8 20:48:28 UTC 2009


Sigh. I meant "non-issue" of course. I hope there are none more mistakes.

Brian Utterback wrote:
> 
> Danny Mayer wrote:
>> Brian Utterback wrote:
>>  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.
> 
> I am not sure what your point is here. I am saying that the security 
> issue is a none issue on Solaris and Windows because of their socket 
> options to allow exclusive bindings. It is a none issue on all other 
> Unixen because of the root priv security model. It is a none issue on 
> firmware because of the inability to have random processes show up. On 
> what operating systems is it actually a problem?
> 
>>> 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.
> 
> Huh? Who was talking about buffer overflows? Not me.  My only point is 
> that the security issue is a complete red herring. The proposed 
> changes do *nothing* to enhance security in any practical sense.
> 
>>   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.
> 
> What scenario are you envisaging? A malicious privileged process on 
> the server that hijacks the port and serves bogus time to target 
> clients, or a malicious privileged process on the client that hijacks 
> the port and causes a denial of service by preventing any responses 
> getting to the ntpd process? As we have seen, neither scenario is 
> viable on either Windows or Unixen. On what system is it really viable 
> at all? And assuming there is one, do you really think that this is 
> really a concern for those people using that platform?
> 
> 
>   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.
> 
> Why?
> 
> 
>> 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.
> 
> No I am not assuming that. The firewall function is now expected to 
> live on the same host. I think most modern Operating systems have that 
> functionality built in. Solaris does. Linux does. Windows does. BSD 
> does. Mac OS does.
> 
> 
>>> 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.
> 
> No, you misunderstood. The complexity is already there, before this 
> change.
> 
>>  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
> 
> Right, but you have missed this point too. If you are using listen-on, 
> your plan also loses the added security, if any.
> 
>>>> 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.
> 
> Of course it does. NFS was designed for unreliability as well, just in 
> a different way. The reason that NTP doesn't use TCP has nothing to do 
> with caring about getting an answer or waiting for the next time. It 
> is because the absolute worse thing that could happen to an NTP packet 
> is to have it get retransmitted later with all the same timestamps as 
> the first time. Wouldn't that be fun, to have the transmit timestamp 
> be wrong by 10's of seconds?
> 
> NFS originally used UDP because of the same time critical constraint. 
> Each NFS stream between the host and client can contain requests and 
> responses from many different processes and threads, operating 
> asynchronously with the data multiplexed. A single dropped packet 
> could result in all of the client processes seeing delays.
> 
> NFS generally does use TCP these days because on a LAN the 
> retransmission timer will be very small and the delays small as well, 
> and on WANs the ability to get it through the firewall takes 
> precedence. Most admins don't like to allow UDP through the firewall 
> because it is almost impossible to make a stateful filter, because in 
> most cases *the outgoing destination IP may not match the returning 
> src IP*.
> 
>>>> 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.
> 
> Completely false. That would require every single UDP server to be 
> binding all interfaces, which is certainly not the case.
> 
>>> 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.
> 
> Irrelevant. We already said that 16 bits was too small. The fact that 
> it was too small for multiple reasons doesn't change anything. And I 
> don't care anymore, it is built into the NTP v4 RFC now.
> 
>>> 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.
> 
> Here is the counter example to your statement above, "every one". And 
> it was already in the same message.
> 
> 
>>> 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.
> 
> Sure. Again, it doesn't matter anymore. But the protocol could have 
> been built to not have the requirement. I don't blame Dave, he has 
> already gone on record that he believed that RFC 1122 (and before) 
> required the IP's to match, so he built the protocol to leverage that. 
> I am just saying had he not made that decision the implementation 
> could have been simpler. We know that there are a few hiccups in the 
> protocol design, (extensions requiring autokey for example) that are 
> more obvious under 20-20 hindsight.
> 
> But the whole issue of the IP addresses matching is not important 
> anymore.
> 

-- 
blu

"The advertising giveth and the EULA taketh away."
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom


More information about the hackers mailing list