null session %U expansion (patch)

[Jeremy Allison]

thwartedefforts at wonky.org wrote:
> 
> On Fri, 30 October 1998, Jeremy Allison wrote:
> > With all other 'security=' levels every packet contains
> > a valid vuid number which is checked before access is
> > allowed.
> 
> I'd like to verify this myself (not that I don't trust you, just
> that I want to fully understand).  Unfortunately, I don't think
> it will apply anyway, because in reply_sesssetup_and_X, the vuid
> stuff isn't used in the place where it's assigning to
> sesssetup_user.  Perhaps it should be.
> 

reply_sesssetup_and_X is where new vuids get *created*.
It is essentially the SMB "logon" call. In non-share
level security Samba creates the vuid in this call and
then sends it back to the client.

> 
> Is this connection really anonymous?  It was previously
> validated, and it is the same connection.  


You are mistaking "connections" with TCP connections.
When I refer to a validated SMB connection I mean an
existing user vuid - created by a sessionsetupandX 
call. Multiple SMB user connections are multiplexed
down one TCP connection to one smbd - that's why
we have the multiple vuid code in Samba.

> The behaviour
> of the client I'm seeing is that I
> open up in Window's Explorer my samba machine.  I click
> on a share.  The share's contents show up, and then between
> 2 and 5 seconds later, the share contents refresh _without_
> user intervention, and apparently reply_sesssetup_and_X is
> being called again, but with an empty username.  This
> effects the reload_services call, and the names of the
> configuration files it subsiquently reads.  It seems this
> only happens once, no matter which share I open.  If
> I open a second share, the client doesn't end up invoking
> reply_sesssetup_and_X again.
> 

What you are reporting here seems to be a client bug, as 
Luke pointed out. The problem is that you as a user have
authenticated to Samba using sessionsetupandX and have
received a vuid. The client machine also does a 
sessionsetupandX *independently of your logon* as
an anonymous user and receives a vuid for this (anonymous)
user. When you ask for a list of resources, the machine
seems to be doing the request to list the shares as
you (using your vuid), however, when it refreshes it 
sometimes seems to be sending the request using the 
anonymous vuid it obtained for itself.

This is a really nasty bug to fix for Samba, as we
*must* believe the incoming vuid from the client as
all our authentication decisions are based upon it.

(Yes this does mean that if you can spoof a TCP session
and use a known vuid then the SMB protocol is open to 
filesystem hijack, but  I'm sure you already knew that :-).

> This is all using NT4SP3 client.  I observe the same thing
> (refresh) when I connect to a NT4SP3 Server, rather than
> samba, although it doesn't actually do anything because
> you can't configure NT Server to have different
> configurations based on user.
> 

There's the rub. That's why they probably haven't detected
and fixed this client bug in NT, because their servers can't
give different resource lists per vuid - Samba can.

> I would agree if this was occuring over a competely new
> connection, but my tests show that it's not.  The connection
> is previously validated, which is proven(?) by the value of
> sesssetup_user that is being overwritten.
> 

The value of the vuid is the critical factor here. If
two SMB requests contain different vuids, then it's 
a different user as far as Samba is concerned.

> If it's from a previously validated session, I want %U to
> not change (keep it's previous value).  If it's a completely
> new connection that is anonymous, then the specified guest
> user.

Can't do that if it's a different vuid in the SMB request.
That would break any security the vuid provides. The Samba
code does what you want now *provided the vuid is the same* !

Cheers,

	Jeremy.

-- 
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------