Security hole?

Andrew Tridgell tridge at
Wed May 6 04:10:13 GMT 1998

> 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? I think win95
clients are more likely to issue a totally unrelated error message or
give "the app has performed an illegal operation".

Are you sure you can tell win95 clients to "go back and authenticate
again" ? What error code do you issue to do this? My bet is that there
is no error code that will make them do this, I've certainly never
seen 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.

> > 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!

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

Cheers, Andrew

More information about the samba-ntdom mailing list