[ntp:hackers] Samba's MS-NTP implementation

David Mills mills at udel.edu
Tue Jul 14 20:16:25 UTC 2009


Harlan,

Wrong number. I did not realize there was to be a TCP call that could 
block other usersl. Clearly, this is a seriously flawed design.

Somebody needs to scarf a copy of the authentication options page and 
insert a section that clearly explains the purpose, method, hazards and 
available references. You really don't want me to write that section. 
Menawhile, I will put up a shrill waring that the mssntp flag should be 
used only for Microsoft networks with no clients other than MS-SNTP.

There already is an #ifdef for the critical section. Goodness, gracious, 
default it off. We run Samba all over the place here. It will happen 
that some Windows users will jawbone our support staff to bring up 
MS-SNTP servers here. There should be a warning about this in the 
autoconfigure help.

Dave

Harlan Stenn wrote:

>Dave,
>
>  
>
>>No, Dave Mills doesn't know that. I understood the call to 
>>send_via_ntp_signd() was nonblocking. If it can potentially block, it is 
>>a showstopperr.
>>    
>>
>
>I have a solid memory of us discussing this - it was one reason you
>insisted the code be disabled by default, and why we wanted to put
>suitable warnings in the documentation.
>
>Regardless:
>
>- It's only a potential problem for people who choose to explicitly
>  enable it
>- We can avoid the problem when we get the event loop code in place
>
>And if you are still concerned about the risk we can throw a suitable
>#ifdef around the actual dangerous bit (perhaps with a #else clause that
>contains an msyslog() call to warn that the code was wanted but not
>enabled) until we can better resolve the issue.
>
>H
>--
>  
>
>>Harlan Stenn wrote:
>>
>>    
>>
>>>>I have been reviewing the code that the Samba team introduced into the
>>>>NTP dev code base and I am seeing a lot of problems that disturb me
>>>>about this contribution. So let me enumerate the problems with the
>>>>implementation:
>>>>
>>>>1) The code uses a TCP socket to call another server. This is even
>>>>though NTP only uses UDP
>>>>   
>>>>
>>>>        
>>>>
>>>So what?  This is the code the Samba team says makes for the easiest
>>>integration with samba.
>>>
>>>That is the entire point of this whack of code.
>>>
>>> 
>>>
>>>      
>>>
>>>>2) The code only seems to try to contact a Samba server but it should
>>>>equally be able to connect to an Active Directory Domain Controller or a
>>>>Kerberos server.
>>>>   
>>>>
>>>>        
>>>>
>>>Why do you say this?  The samba folks know what they need, and sent us
>>>code to do what they need.
>>>
>>>What problem are you trying to solve?
>>>
>>> 
>>>
>>>      
>>>
>>>>3) The code blocks on the connect, the send (write) and the recv (read)
>>>>calls all of which violate the basic requirements of NTP.
>>>>   
>>>>
>>>>        
>>>>
>>>Yes, Dave Mills and I both know this and discussed this.
>>>
>>>Until we get event-loop code into ntp, the samba interaction *can*
>>>block.
>>>
>>>Therefore we default the samba code to "off" and we warn people (at
>>>least we *should* be warning them) about the problems they *may* have if
>>>they use this code.
>>>
>>>And as I understand it, the new MSSNTP 'restrict' code can limit the
>>>networks that ntpd will even talk to about this.
>>>
>>> 
>>>
>>>      
>>>
>>>>I am unsure of the affect of using this on a Windows system.
>>>>   
>>>>
>>>>        
>>>>
>>>Why would you want to run Samba on a Windows box?
>>>
>>> 
>>>
>>>      
>>>
>>>>4) The code uses AF_UNIX instead of AF_INET or AF_INET6 as appropriate
>>>>   
>>>>
>>>>        
>>>>
>>>What problem are yo trying to solve?  This stuff is all on the local
>>>machine.  What is the problem with using an AF_UNIX socket to talk
>>>between ntpd and samba running on a Unix box?
>>>
>>> 
>>>
>>>      
>>>
>>>>5) The time for another server to respond is indeterminate and cannot be
>>>>relied upon.
>>>>   
>>>>
>>>>        
>>>>
>>>Yes, so what?  This is also going on (near as I can recall) in between
>>>T2 and T3, so the amount of time it takes doesn't really matter.
>>>
>>> 
>>>
>>>      
>>>
>>>>6) The requirement that it waits for another server makes it easy to
>>>>mount a DOS attack on such an NTP server.
>>>>   
>>>>
>>>>        
>>>>
>>>Yes, and since this service should only be set up to support local
>>>users, there is less risk.  And we document this.
>>>
>>> 
>>>
>>>      
>>>
>>>>7) The reliance on another server increases the likelihood that the
>>>>jitter and delay will increase enormously in unexpected and unreliable
>>>>ways and that is something that NTP cannot afford.
>>>>   
>>>>
>>>>        
>>>>
>>>Says who?  And if indeed this interaction is between T2 and T3, where is
>>>this problem you speak of?  And if this really does turn out to be ab ig
>>>deal, we'll hear about it, see if we can fix it, and either way folks
>>>can decide to use it or not.
>>>
>>> 
>>>
>>>      
>>>
>>>>8) There maybe some issues over the copyright of the protocol which is
>>>>covered under Microsoft's Open Specifications copyright but I am not a
>>>>lawyer and cannot say if there are any legal issues involved with this
>>>>code.
>>>>   
>>>>
>>>>        
>>>>
>>>I'm not a laywer either so neither can I.  We got the code in good
>>>faith.
>>>
>>> 
>>>
>>>      
>>>
>>>>This is so at variance with the NTP design requirements that I am
>>>>recommending that we completely remove the Samba contribution from the
>>>>4.2.5 code at this time. If at some point in the future this can be done
>>>>without involving a third system then it can be reconsidered. Even if
>>>>this is released we should explicitly be turning off this capability and
>>>>require that anyone who wants to use it turn it on.
>>>>   
>>>>
>>>>        
>>>>
>>>It is *already* off by default.
>>>
>>>It *already* requires specific action to turn it on.  
>>>
>>>And I hear your recommendation.  We (me, Dave Mills, a bunch of other
>>>folks) have been discussing this proposal for quite a long time now
>>>(since May 2008, and before that, Novermber of 2006), and I suspect you
>>>knew about this.
>>>
>>>Even if it wasn't so late in the game, the dangers of enabling this
>>>capability are well understood and documented, and there are significant
>>>complications if we do *not* have this capability.
>>>
>>>Furthermore, I believe most of the "danger" in this capability will go
>>>away as soon as we have a useful event-loop in the mainline code.
>>>
>>>So far I've heard only good things about this code, and no reports of
>>>problems.
>>>
>>>That's good enough for me, given the current default behavior and the
>>>warnings and caveats to those who intend to use it.
>>>
>>>I am again reminded of my favorite between-the-lines Bible Quote:
>>>
>>>Blessed are those who get what they deserve.
>>>
>>>H
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>hackers mailing list
>>hackers at lists.ntp.org
>>https://lists.ntp.org/mailman/listinfo/hackers
>>    
>>



More information about the hackers mailing list