Security hole?

[Luke Kenneth Casson Leighton]

On Wed, 6 May 1998, Andrew Tridgell wrote:

> > not really: if the SMBsessetupX was made with "null session" and the first
> > tconX made with a null password to IPC$, we do not put out an error
> > message when further tconXs come in [to connect to shares].
> 
> tconX always has a null password in user level security (the password
> field would be meaningless anyway).
>  
> > if we did, then the win95 clients would drop the connection and re-issue
> > an SMBsessetupX, but this time with a username/non-null-password/domain
> > connection.
> 
> errr, is this based on wishful thinking or experience?

experience.

> I think win95
> clients are more likely to issue a totally unrelated error message or
> give "the app has performed an illegal operation".

no... ah, actually what _can_ happen is _three_ SMBsessetupXs are sent.

1) null session SMBsessetupX.  server accepts.  null tconX to IPC$.
server accepts.  null tconX to \\server\share: server rejects; client
drops connection.

2) username/non-null-password/domain SMBsessetupX.  server accepts.  null
tconX to \\server\share.  server accepts.

****OR****

2) username/non-null-password/domain SMBsesssetupX.  server _validly_
rejects because the user/pass combination is wrong; client drops
connection.

3) Network Neighbourhood throws up a password dialog (on win95) or a
user/password dialog (on NT).  new username/password/domain SMBsesssetupX.
server accepts valid password.  null tconX to \\server\share.  server
accepts.

 
> Are you sure you can tell win95 clients to "go back and authenticate
> again" ?

yes.

> What error code do you issue to do this?

can't remember.  i mistakenly put the standard DOS "invalid password" one
whatever it is, once, and got a non-null-password SMBsesssetupX
immediately afterwards.

> My bet is that there
> is no error code that will make them do this, I've certainly never
> seen one.

there is one.

> Remember that SMB authentication is a very fragile thing. Clients
> don't do the "sensible thing" when they get an error back, they tend
> to die horrible deaths instead.

we will have to walk the thin line to get the right path: it exists :-)
 
> > > The good thing is that if there is a problem then it will probably be
> > > easy to fix. The solution would almost certainly be to return a
> > > particular error code in tconx if the vuid matched a null
> > > session.
> > 
> > this is what i have seen NT server do, and the win95 or nt client then
> > sends a proper "user/non-null-pass/domain" request.
> 
> again, send me a sniff that shows this. I'm highly skeptical!

will do.
 
> note that my skepticise is based on spending quite a bit of time
> (admittedly quite a while ago) trying to get MS clients to do exactly
> this. I even tried modifying smbd to cycle through all possible error
> codes one at a time trying to find one that would make win95 clients
> behave like this. Now maybe I missed one, but I'm not going to be
> convinced by anything less than a sniff :-)

i'll do me best, andrew.