uucp

dave@utcsrgv.UUCP (Dave Sherman) (10/28/83)

Many systems have a fully readable/writeable /usr/spool/uucp
directory. We all know that this means that traffic (mail etc.)
is vulnerable to inspection and destruction. Did you know that
this can also affect uucp's own files such as L.sys?

If you go into the spool directory, delete a data file which is
on its way out of the system, and link /usr/lib/uucp/L.sys to that
file name, uucico will copy it without checking for permission.
(Uucp does check for permission if you try to explicitly copy a
file to which you do not have access.) For the bug to exist,
uucico must be running setUID=>uucp. Also, your uucp spool and
lib directories must be on the same file system. On many
4.1bsd systems, all of these conditions are true.

Here's one way to demonstrate the bug.
   This explanation will assume that we are going to copy the
"L.sys" privileged file to system "lsuc".

   Do the following:
    uucp /etc/motd lsuc!~uucp/junk
/etc/motd is simply a convenient file to copy; anything will do.
When uucp is finished, it will have created a copy of /etc/motd
in a data file named /usr/spool/uucp/D.lsucn1234, with some
four-digit number in the place of "1234". A perusal of the
/usr/spool/uucp directory will identify the exact file name.

   Now do this, substituting the appropriate digits for "1234":
    cd /usr/spool/uucp
    rm D.lsucn1234
    ln /usr/lib/uucp/L.sys D.lsucn1234
Presto! The link works because both the spool directory and
uucp's own files are on the /usr filesystem. When uucico is next
invoked to call system "lsuc" (or when lsuc next calls), it runs
as  setUID  and  happily  copies  the  L.sys  file  into
/usr/spool/uucppublic/junk on the lsuc system. There it can be
read, or copied back if the user has no access to lsuc. Uucico
even unlinks the file when it is done, thus cleaning up all evi-
dence of the security breach.

   Although I have not tested it (not wishing to destroy any
files currently owned by uucp), it seems likely that the same bug
could be exploited to change the L.sys file. The user would have
to figure out ahead of time what name the file would be given
when uucico at the receiving end created it, so it would take a
little more planning than the above example. (Once the name was
figured out, the user would simply link L.sys to that name, and
then a subsequent "creat" by uucico would cause the data file
write to actually write into L.sys.)

   The fix to the bug is to add a protection mode check to
uucico, just as there is in uucp. A quick look at the source
suggests that the fix should go into the cntrl() routine in
cntrl.c, just before the fopen() on the data file. This would
slow down uucp generally, but because of the batch nature of
uucico seems to be the only way of closing the security hole.

   It should be noted that on many systems, the basic information
in the L.sys file is available anyway by invoking "uucico -r1 -sxxx -x9",
which in the course of diagnostic information will present the
login name and password for system "xxx". Some versions of uucp suppress
displaying at least the password.

   It should also be noted that the information in L.sys isn't that
important anyway, since the uucp password can't give you a shell on
any system. But it would be unpleasant if a malicious user disabled
callouts by mucking up L.sys or its related files.


Dave Sherman
Toronto

P.S. If anyone out there is silly enough to be running uucico
setUID to root, you had better change it quick...
-- 
 {cornell,decvax,ihnp4,linus,utzoo,uw-beaver}!utcsrgv!lsuc!dave

thomas@utah-gr.UUCP (Spencer W. Thomas) (10/31/83)

I noticed that uucico in 4.2Bsd won't let you specify the -x option
unless you are root.

=Spencer

wls@astrovax.UUCP (11/02/83)

This is probably a tired old subject but could anyone who has the diff's to
make /usr/spool/uucp something other than drwxrwxrwx please send them to me.
We are running 4.1BSD and have the uucp which comes with 4.1 BSD (but which
has been much munged).
-- 
Bill Sebok	Princeton Univ. Astrophysics
{allegra,akgua,burl,cbosgd,decvax,ihnp4,knpo,princeton}!astrovax!wls

guy@rlgvax.UUCP (Guy Harris) (11/02/83)

The "-x" option can't be given to any UUCP program under the 4.2BSD UUCP
unless your UID is under a certain magic number, specified in "uucp.h".
We changed it so that it wouldn't let you use the "-x" option unless you had
read permission on /usr/lib/uucp/L.sys, which avoids magic numbers and gives
you the effect you really want (i.e., people can't run "uucico" to some
system, turn the debugging up, and get told that system's login sequence for
UUCP).

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy

fair@ucbvax.UUCP (11/06/83)

Symbolic links under 4.2BSD make this even more difficult to stop.

	Erik E. Fair	ucbvax!fair	fair@ucb-arpa.ARPA