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' #9 1985-03-11 (1 file, 2550 bytes)
NOTICE: recognises the rights of all third-party works.


Date: 11 Mar 1985 0010-MST (Monday)
Subject: Security Mailing List, # 9


Editor's corner

        The computer did it!! Not me!! I only program the thing!!

        He mistakenly bumped a counter when I wasn't looking and made the
        last list I sent out eight instead of seven.  I'm so ashamed (of
        him, of course).  His pay has been docked, and I hope it'll never
        happen again.

        ===> Issue 7 doesn't exist; A number was skipped. <=============

        Except for issue #5. Apparently ihnp4 ran out of tmp space the
        night #5 went out, and everyone with ihnp4 'tween me and thee lost
        out. I'm sending it out to the affected parties again tonight.

        Lots of fun, this job.

Newcomers to the list since last issue:
        Russell L. Brand (brands@lll-crg)
        D. Byle (dbyle@pyrcorp)
        Marc Lesure (lesure@asuvax)
        R Novak (rnovak@pyrcorp)


Date: Wed, 30 Jan 85 19:40:58 nst
From: Andrew Draskoy <allegra!garfield!andrew>
Subject: Why setgid is unsafe in pre-4.2bsd

To see the problem, first consider how easy it is to create a file owned
by yourself, but in a group that you don't normally have access to.
Any setgid programme or shell script that creates file will do.  If you
can get access to a user's account who is in a group you want, you can
create such a file.  This can happen in any number of ways, as you are
all aware.  John Pierce's setuid shell script bug (posted in list #3)
compounds the problem, especially since either a setuid or setgid script
will potentially let you at a group.  If that wasn't enough, we can look at
all the bugs/features kindly given to us by folks at Berzerkly:
Here is what a chown(2) call should look like:
chown(path, owner, group)
and guess what appears in 4.1bsd's ex3.7preserve (which is setuid root):
chown(path, owner)
Evidently someone forgot that chown(2) also changes the group.  While
they were at it, they forgot about lint.  Thanks to the bsd C-compiler,
this gets translated to
chown(path, owner, 0)
Voila!  A file in group zero, owned by you.  All you need to do is get
your editor session preserved, which is easy enough.  How many of you
use group zero as a privileged "root" group?

Now the crunch:
Prior to 4.2bsd, you could set any mode you liked on any file that you
owned.  So how about setting the setgid bit on a file you created using
one of the methods outlined above?  A simple application of dd will let
you put anything you like in the file, while leaving the group intact.
Since you can change the modes at any time, the file can remain very
inconpicuous for a long time.  To detect files like this, you would
really have to do regular find(1)s from / to look for files in groups
that their owners are not in.  This is of course, a pain.

Now, this is not really a problem because it only occurs on systems with
bugs and security leaks.  On the off chance that this does not describe
your system (:-), you may want to implement a fix.

What we did was modify the chmod system call to not let anyone setgid
a file who's group was different from the effective group of the process.
This spoils the functionality of chmod(2) a bit, but most programmes will
not need to do anything outside this restriction anyway.

Andrew Draskoy


From: denelcor!brl-bmd!
Date:     Thu, 7 Mar 85 22:47:09 EST
Original-From:     Ron Natalie <ron@BRL-TGR.ARPA>
Subject:  Process group bug

This bug is fixed in 4.3 BSD and the BRL VAX UNIX rel 3.  Of course,
the fix causes subtle things to break like rlogin and some of the
fancier shells.  These were fixed for the most part as well.



Date: Thu, 7 Mar 85 15:35:52 pst
From: hao!ucscc!root (00050000)
Subject: Treatise on uucp needed

I wish somebody would lay out how to set up a uucp system with
all the permissions and passwd entries and everything.  Ours presently
runs wide open; i.e. all the files mode 666 and directories mode 777.
If I change anything it breaks.


Subject: Re: Security Mail List,  # 5
Date: 06 Mar 85 09:36:50 PST (Wed)
From: David Barto {ucbvax|decvax|ihnp4}!sdcsvax!celerity!barto <ihnp4!sdcsvax!celerity!barto>

 I seem to have missed #5 of this list,  I have 4 and 6.

 As a side note, I would be interested if anyone else applied the
 fixes to the shells (sh/csh) which close the suid shell script problems.

 I have them in, and they work, preventing users from getting shells
 with 'root' or other privledges, beyond there own.

 Keep your users at bay, get the fix in! 

David Barto                   akgua!celerity!barto
{decvax || ucbvax || ihnp4}!sdcsvax!celerity!barto
"If you are using more than 10 sites to get here, you are taking the long way"


                    The UNIX security issues mail list

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