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

Harlan Stenn stenn at ntp.org
Tue Jul 14 20:20:35 UTC 2009


Dave,

I'll take care of it.

H
--
> 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
> >>    
> >>
> 
> _______________________________________________
> hackers mailing list
> hackers at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/hackers


More information about the hackers mailing list