Security hole?

[Luke Kenneth Casson Leighton]

On Tue, 5 May 1998, Andrew Tridgell wrote:

> They *could* use the trust account, but I don't think they do (not for
> browse synchronisation anyway). 
>  
> > if your NT DC is contacting a non-NT-like machine, then it can use null
> > sessions.
> 
> again, what could be done and what is actually done by MS OSes are two
> different things. I believe 95 and NT use null sessions for browse sync.
> 
> > there is.  the first (interactive) connection [by an nt or 95 client] is
> > subverted by a null session.
> 
> nope. Send me a sniff of a win95 box doing a null session connect for
> a user initiated browse and then maybe I'll believe you. 

i don't use win95: i can do an nt wksta one, though.

 
> win95 and NT always try a null password first, but that is not a null
> session. As long as you haven't stuffed around with the
> GUEST_SESSSETUP option at compile time in Samba

i haven't.

> then the null password
> will fail when the server is in user level security. The client then
> sends a proper session setup.

no it doesn't :-)  it converts the user to the guest account (extract from
reply.c): 

  /* If no username is sent use the guest account */
  if (!*user)
    {
      strcpy(user,lp_guestaccount(-1));
      /* If no user and no password then set guest flag. */
      if( *smb_apasswd == 0)
        guest = True;
    }

  strlower(user);

  strcpy(sesssetup_user,user);

  reload_services(True);

  add_session_user(user);

  /* Check if the given username was the guest user with no password.
     We need to do this check after add_session_user() as that
     call can potentially change the username (via map_user).
   */

 
> John tried to convince me that NT and 95 could do a null session
> connect a few weeks back. We ran a sniff and found it didn't. 
> 
> >  multiple tconXs are sent.  if the first is to IPC$, then a null
> > SMBsessetupX is sent.  subsequent tconXs do not have a username in
> > them
> 
> tconXs never have usernames in them (unless you count the % hack).

exactly: therein lies the problem.
 
> I could believe that this could be a problem with NT domain logins. It
> is just possible that a NT domain workstation will cache a null
> session used for browse synchronsation and carry that over to a
> attempted login. If you show me that this happens then I'm sure we can
> find a workaround.

it does, and so does win95.  i don't use win95 any more, but i can get you
an NT trace.

> >, so samba does not have a substitution for its [homes]
> > connection, and hence the username share that is created by [homes] does
> > not appear: you get a share named after the guest account, instead.
> 
> what worries me here is that this is exactly the symptoms you will get
> if you muck with the GUEST_SESSSETUP option (among other nasty side
> effects). Are you _sure_ you didn't have GUEST_SESSSETUP set when you
> saw this? 

i am sure: it was at the default.  i've never recompiled with
GUEST_SESSETUP at anything other than the default: i don't like it. 
 
> Also, are you sure it was a null session (ie. username was null in
> sessionsetupX) and not just a null password? I'm very skeptical :-)

username was NULL: password was "length 1".  i wouldn't have had a share
named after "nobody" come up if it wasn't.

  
> > the difference is between a share level connection and a user level
> > connection, and we currently still do not make the distinction correctly.
> > yes it does.
> > 
> > > A
> > > Win95 or NT client cannot be made to do a null session connect when
> > > using network neighborhood or any other user initiated
> > > browse.
> > 
> 
> I believe we do, but a sniff will convince me otherwise :-)
> 
> > i see this occur all the time.  you have to deliberately disconnect the
> > win95 or nt client session (use SRVMGR.EXE) and then do view | refresh on
> > the "shares" window.
> 
> I just tried it and didn't see a null session in a sniffer. Everything
> worked fine. This was with a NT4wks client doing a domain logon to a
> Samba server (current CVS tree).
> 
> > this may be the case when talking to non-NT-like systems, which samba can
> > currently be considered to be one such system in the browse sync respect.
> > to solve this problem fully, we will need to investigate browsing between
> > NT Trusted Domain Controllers.
> 
> as far as I know browse synchronisation works the same between NT as
> between 95 and NT (as far as authentication goes at least). Browse
> listing (ie. obtaining a list of shares) works differently, but thats
> a different kettle of fish!
> 
> Cheers, Andrew
>