[242] in World Wide Web
Re: mosaic security holes
daemon@ATHENA.MIT.EDU (yandros@MIT.EDU)
Thu May 5 20:17:33 1994
From: yandros@MIT.EDU
Date: Thu, 5 May 94 20:17:00 -0400
To: dcns-dev@MIT.EDU, www@MIT.EDU, web-request@MIT.EDU, webmaster@MIT.EDU
Cc: cdemello@MIT.EDU, tjm@MIT.EDU
In-Reply-To: <9405051323.AA24287@timesink.MIT.EDU> (message from Christina Diete DeMello on Thu, 05 May 94 09:23:58 EDT)
Some people have seen a report from a <bigmac@dram.erg.sri.com> about
WWW and specifically Mosaic security holes. Greg Hudson and bert
Dvornik have already answered these concerns acurately and well
(thanks, guys), but I thought I'd respond in a little more detail to a
wider audience. Please pare down any responses to avoid irrelevant
traffic; sending just to `yandros@mit.edu' and `www@mit.edu' is
appropriate; interested parties should add themselves to the
www@mit.edu/charon.mit.edu:/usr/spool/discuss/www public mailing
list/discuss meeting pair (plug plug :-)
The heart of the matter:
Mosaic clients run on your machine, connecting to information
servers across the Internet. The servers feed the files to the
client, and the client stashes them in a local disk directory while
you are viewing them for quick access. To accomplish this, the
local client has to create and delete lots of temporary files, as
well as perform other UNIX shell level functions. Well, the client
program running as you on your machine does not know anything about
file names or the like, so it asks the server for them. The server
creates a string of text, like " /tmp/foo.html " and then send it
and a create or delete signal to the client on your machine. The
client then uses the system call to execute a /bin/rm of the string
sent it. It does this in a standard shell.
This is completely untrue. I am aware of no condition under which the
server ever sends a temporary filename to the client. There is no way
under the protocol as it is now to do such a thing if you wanted, and
you wouldn't; wether or not to use temporary files *at* *all* is
wholly the province of the particular client, much less the names of
said files. This person is mistaken or confused.
Most likely this person is confused about a problem that appeared
`recently' with Mosaic for X version 2.2. Under this version of
Mosaic for X, URL types corresponding to `remote sessions' (that is,
telnet, tn3270, and rlogin) URLs were handled by contructing a
commandline like ``xterm -e telnet host.name'' and then executed via
the system() C function. The problem came about when hostnames were
formatted like ``host.name; rm -rf /', resulting in a commandline like
``xterm -e telnet host.name; rm -rf /'', which, when passed to the
system call, would act exactly the same would it would when types into
a shell; it would run an xterm running telnet to host.name, and when
that was done, it would run `rm -rf /'. I patched this in an
acceptible manner several weeks ago (by only allowing characters valid
in a hostname under RFC 1123). A technically superior patch would
avoid use of the system() command altogether, but that's something for
a latter time.
NCSA's SDG (Software Development Group) shipped Mosaic for X versions
2.3 and 2.4 (2.3 accidentally including debugging code) about a week
after I put my patch into testing (my memory is fuzzy as to exact
dates; this was several weeks ago). I disliked 2.4's solution
(silently dropping the invalid request) and haven't had time to
reintegrate the numerous patches Sal Valente and I have made to 2.2
into 2.4 yet, so the version in the sipb locker (the one virtually
everyone is using) is still 2.2 based.
As I mentioned above, there is a concerted effort going on right now
to re-write the clients from the ground up to remove this hole, but
they are months out.
We fully plan on retrieving and installing the secure versions of
the mosaic cleints when they become available
These later quotes from this person indicate a sever state of
confusion; it's virtually impossible these days to look for Mosaic for
X and not see signs saying ``Get the new version'' everywhere. These
patched clients have been available for several weeks.
That said, there was one very good suggestion in the mail I recieved:
please be careful.
:-)
