Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site scgvaxd.UUCP
Path: utzoo!watmath!clyde!cbosgd!ukma!psuvm.bitnet!psuvax1!burdvax!sdcrdcf!trwrb!scgvaxd!brian
From: brian@scgvaxd.UUCP (Brian Zill)
Newsgroups: net.bugs.4bsd
Subject: Re: Man(1) makes "cat" files with wrong mode and ownership
Message-ID: <503@scgvaxd.UUCP>
Date: Tue, 31-Dec-85 22:47:07 EST
Article-I.D.: scgvaxd.503
Posted: Tue Dec 31 22:47:07 1985
Date-Received: Fri, 3-Jan-86 01:44:09 EST
References: <2093@phri.UUCP>
Reply-To: brian@scgvaxd.UUCP (Brian Zill)
Distribution: net
Organization: Hughes Aircraft Company, El Segundo, CA
Lines: 38
Keywords: man secuity hole
Summary: Running Man(1) setuid introduces serious security hole.

In article <2093@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
>Index: ucb/man.c 4.2BSD
>       ucb/Makefile 4.2BSD
>
>Description:  When you run "man x" and the cat file has to be made, it is
>       left with mode 0666, and owned by whoever happened to run man.  This

>
>Fix:  Install the following 2-line patch.  Also, change the Makefile so
>       man is installed set-uid.  I'll leave it to other, smarter, brains
>       to figure out if this opens up any security loopholes.

Yes, this is a major security problem.  man calls more to page the longer
manual entries, and more has a shell escape...  Ta Da!  you're superuser!
What we did at Harvey Mudd College where I go to school is to put some
code in to set the effective uid and gid back to their real values after
the fork that provides the shell escape in more.  We have other priv'd
programs there that use more as a pager and this seemed the simplest place
to close this particular hole.  (Yes, this also gets the "vi" escape).

Probably more important than this is to realize that whenever possible,
don't run things setuid when setgid will do.  (We have our man run setgid
to group man and have the /usr/spool/man/cat directories writable to that
group.  Also, system people are in group man so they can add new entries)
That way, even if you do leave a security hole, you're not giving your
entire system away.  Making a program setuid without thinking carefully
about is one of the two most common ways (in my limited experience) in which
security holes get added to 4.2 (the other is having root programs write to
world writeable dirs), too many holes come with the system as it is.

        Yours for securer systems everywhere,
                                                --Brian

P.S.    Anyone know what happened to the securiy mailing list?  I haven't
        seen an issue in months and have some things to contribute.

Here: {allegra,ihnp4,seismo}!scgvaxd!brian
There: {allegra,ihnp4,seismo}!scgvaxd!muddcs!brian