the win95 bug, an explanation?

[tridge () arvidsjaur anu edu au (Andrew.Tridgell)]

The following is something I posted to comp.protocols.smb. It may
offer some insight into how the bug got into the final distribution of
win95.

It really underlines the fact that when writing a server you need to
be very careful not to make assumptions about how the client will
behave. The server needs to assume all clients are potential enemies :-)

Andrew

PS: If you don't have any idea what Samba and smbclient are then have
a look at http://lake.canberra.edu.au/pub/samba

PPS: If you don't have any idea what win95 is then buy a newspaper :-)

----

I thought I'd post a quick note that may help explain some of the
contradictory things coming out about the "cd ..." and "cd ../" bug.

You first need to realise that the SMB protocol (which is what Win95
and Samba use for file sharing) doesn't actually have any notion of
the current working directory built in. Thus the command "cd ..." in
smbclient doesn't actually have to produce any network output at
all. Instead the protocol uses full path names for all files
referenced over the net. When you give a "cd" command to smbclient it
just remembers the directory you want and prepends this to the name of
all files you do things to.

Despite this, smbclient does actually produce some network output when
you type "cd ...". It sends a "SMBchkpth" which asks the server "is
the following path valid". This is just so smbclient users know when
they have mistyped the directory name.

During the beta of Win95 the "cd ..." bug was reported to MS (by me
and probably others). They responded quickly and added a check in
SMBchkpth to make sure that a SMBchkpth on something containing "..."
failed. This made smbclient return the familiar message: "chkpath:
ERRDOS - ERRbadpath (Directory invalid.)" and fail the directory
change.

The reason I know that this is where they added the fix is that if you
change the chkpath() routine in smbclient to always return True then
the "cd ..." bug is still there in the Win95 final release. You can do
a "cd ..." (which will then produce no net output) and then do what
you like. Even with a unpatched smbclient you just have to preface all
filenames with \...\ to send the commands without the SMBchkpth.

So when people say that MS lied about it being fixed in build 490 (or
whatever) you need to be careful. They probably really did think they
fixed it, its just whoever did the fix didn't realise that you don't
need to call SMBchkpth at all. And maybe whoever tested the fix did a
"cd ..." got the ERRbadpath back and said "fixed".

Then later when the "../" problem was reported to MS they may have
thought "this is just another instance of that earlier bug that we've
fixed already". I'm guessing here, of course.

The proper fix needs to be applied to ALL filenames received from the
client, not just the ones in SMBchkpth. I assume this is what has been
done in the recently released patch. I'll try it when I get some spare
time.

Andrew