Security hole?

[Andrew Tridgell]

> ah, good point.  information interchanged between... ah, but if you have
> two NT Domain Controllers, then they can interchange information using the
> "trust" account system (not that i've fully investigated this...)

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. 

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 then the null password
will fail when the server is in user level security. The client then
sends a proper session setup.

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).

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.

>, 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? 

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 :-)
 
> 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