The 'Security Digest' Archives (TM)

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

ARCHIVE: Zardoz 'Security Digest' - Archives (1989 - 1991)
DOCUMENT: Zardoz 'Security Digest' V1 #30 1989-08-23 (1 file, 6427 bytes)
SOURCE: http://securitydigest.org/exec/display?f=zardoz/archive/130.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT


Security Digest Volume 1 Issue 30

subject(s):

            Warning! Secure rexd
            [cert@SEI.CMU.EDU (Computer Emergency Response Team) : CERT Internet
            crc for all files
            Re: Security tools
            getty/login enforced port restriction
            Security tools
            chown -vs- SunOS
            Security package available
            suid shell
            SunOS 4.0 security features
            Re: Security Holes

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

Date: Wed, 23 Aug 89 14:08:28 PDT
From: neil (Neil Gorsuch)
Subject: Warning! Secure rexd

[ Received on the sun-managers mailing list - Neil ]

Pursuant to a bug report, I have been informed by Sun that the secure feature
of rexd (the -s option documented in the manuals) performs no function at this
time. DES authentication does not exist for rexd or the on(1) command, and
is not expected to before 4.1FCS.

At present, with rexd enabled on a workstation there is no way to prevent
another user on another wholey unrelated system from using the workstation's
CPU, disk, etc., for his/her own purposes.

Sun informs me that this applies only to the on(1) command and rexd; in
particular, DES authentication in secure RPC is functional.

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

Date: Wed, 16 Aug 1989 17:56:44 CDT
From: Werner Uhrig <uunet!rascal.ics.UTEXAS.EDU!werner>
Subject: [cert@SEI.CMU.EDU (Computer Emergency Response Team) : CERT Internet

        why would such a notice be posted publicly without at least an
        advance notice to the SECURITY-list ?!

[ I just work here 8-), they didn't send me any advance material
  regarding any internet problems. - neil ]

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

Date: Wed, 16 Aug 89 22:38:06 EDT
From: uunet!b-tech.ann-arbor.mi.us!zeeff (Jon Zeeff)
Subject: crc for all files

A smart hacker will make sure the sum for a replacement program is the
same as the previous one.  I have a couple of programs for doing crc
checks (with a local crc seed value) on a whole file system if anyone
wants them.  They also check for permission changes, etc.

[ Please send them to neil@cpd.com and I will include them in the
   archives.  I got netlib mostly working last night on the publicly
   accessable archives, now all I have to do is to only allow the
   security archives to be sent out to security list addresses - neil ]

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

Date: Thu, 17 Aug 89 10:01:28 -0400
From: uunet!att!ho95c!wcs
Subject: Re: Security tools

In Security Digest V1 #29, uunet!devon.lns.pa.us!paul (Paul Sutcliffe Jr.) wrote
> In Security Digest Volume 1 Issue 28, sechreset@uther.CS.ORST.EDU wrote:
> | I am looking for a few programs that will help me tighten up security
> | [...]
> | A getty that restricts logins only to those that are on an access list
> Personally, I think that checking usernames against an `access list'
> should be login's job, not getty's.  A `freely redistributable' login

It should be done at login time, and not by getty, but it should NOT be
wired into the login code either.  In a System V /bin/sh environment,
all login sessions execute /etc/profile before any user code, so it's
easy to put calls to whatever security checker you want there:
        if security-checker $LOGNAME $LOGTTY `date`
                then echo "GO AWAY AND COME BACK TOMORROW" ; exit 99 ; fi
In a more general environment, you can't depend on /etc/profile,
and there are some security features you'd like to use whether the
login succeeded or failed, but the way to do this is to put hooks into
login to call /etc/local_security instead of making login do the work.
This allows you to do your local checking in a shell if you want, and
simplifies customization.

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

Date: Thu, 17 Aug 89 09:03:31 PDT
From: uunet!ptsfa.pacbell.com!dmt (Dave Turner)
Subject: getty/login enforced port restriction

In Security Digest Volume 1 Issue 29 Paul Sutcliffe Jr and John f. Haugh II
were talking about getty/login restricting logins only to those that are on
an access list.

It is possible to add checks in /etc/profile (System V) so that only
certain users (uid's, gid's or lognames) are allowed on certain /dev/ttyNNs.

The simplest version consists of if [ ] statements naming the user and tty
but a version with a file of ttys and the allowed users is better.

If an unauthorized user is on one of the ports, /etc/profile may do an
exit so that the line is dropped and the user gets hung up.

If the source to login.c is available, this can be done there also
with the same results.

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

Date: Thu, 17 Aug 89 11:05:18 EDT
From: Jonathan Bayer <uunet!ispi!jbayer>
Subject: Security tools

The following are the security programs from the book:
"UNIX System Security" by Patrick Wood & Stephan Kochan.  If there isn't a
copyright problem please publish it in the security digest.  Thanks.

[ I will put them in the archives after contacting the authors - neil ]

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

Date: Fri, 18 Aug 89 17:47:33 EDT
From: uunet!orion.mc.duke.edu!bet (Bennett Todd)
Subject: chown -vs- SunOS

First, let me describe how I *think* things work currently. If I'm
wrong, someone please correct me, and please ignore the question that
comes after, since it won't make sense.

In BSD UNIX, to avoid making disk space accounting seriously bogus
and/or impossibly complicated, chown(2) is prohibited to normal users.
System V, lacking the accounting, makes chown(2) (and thus chown(1))
usable to normal users for giving away files. Since normal users can
chown files away in System V, various security checks and modifications
have been made to remove the obvious security holes. BSD lacks these
checks, therefore simply making /etc/chown setuid root makes it
straightforward to burgle the system.

We don't run disk space accounting. I seriously want to allow users to
be able to give away files, after the style of System V. Here's my plan.
I intend to write a setuid-root C program, which makes the following
checks:
        1) The user invoking must own the file that is being given away
        2) The user invoking must own the directory containing the file
        3) Files may only be given to user IDs greater than 100
        4) Any setuid/setgid bits will be stripped.

Here's the question. If my understanding is correct about how things
currently stand, and if I implement a chown(1) with the checks I
described, will I be introducing any security holes other than the
ability to defeat accounting?

If I can implement such a critter, I intend to make the source available
to anyone who would be willing to check it over for me, and if it seems
secure, I intend to post source to comp.sources.unix or some such.

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

Date: Sat, 19 Aug 89 17:19:07 EST
From: Gene Spafford <uunet!cs.purdue.edu!spaf>
Subject: Security package available

Forwarded for Dan Farmer (one of my students):

 Dear Fellow (Security-Minded) Netters:

[ I am checking it out now - neil ]

    I have finished a beta-release of a UNIX security checker, and
would like to get volunteers to try it out :-).  Written in Bourne
shell, generic commands (awk, sed, etc.) and some C, the system is
basically a shell script that runs several small security programs.
Theoretically (at least), it finds the following problems on a generic
UNIX system, and then mails the results to whomever is in charge, if
indeed any problems do exist:

-  Checks /dev/*mem and all devs listed by "/etc/fstab" command for
world read/writability.

-  Checks special/important directories and files for "bad" (world
writable, whatever) modes.  (/etc/passwd, /bin, etc.)

-  Checks against /etc/passwd for crummy passwords (user selectable,
it can be as vigorous or as lax as you wish.)

-  Checks /etc/passwd for non-unique uids, invalid fields, non-numeric
user ids, etc.

-  Checks /etc/group for non-unique groups, invalid fields, non-numeric
group ids, etc.

-  Checks all users' home directories and their
.login/.cshrc/.rhosts/.profile/etc. files

-  Checks all commands and paths listed in /etc/rc* for writability.

-  Includes the world famous U-Kuang expert system.  Written by Robert
Baldwin, this basically checks to see if a given user (by default root)
is compromisible, given that certain rules are true.  Kind of hard to
explain in a sentence, but worth the price of admission.

-  Checks the system for _changes_ in SUID status.  This is the one (the
only) program that should be run as superuser, because it runs a "find"
on all SUID programs from the / directory, and then use that as a reference
file for future runs.

   The whole package has all the source code, Makefile, documentation
(mostly in the form of a paper on UNIX security), and all the good stuff
that you will need to run it.  It is available to anyone who wants a
Beta copy, provided that you:

1)  do not release it to anyone else, until the final (1.0) version is
released.

2)  give me back (at least) a little feedback on what you think of
the package, in the form of curses, praise, or whatever.  As noted in the
package, I am actively seeking both changes in my programs, or better,
faster, and more portable programs to add to the final version; you will
be duly praised in the documentation and by your peers.

3)  Obey Robert Baldwin's copyright notices!

4)  give me a valid e-mail address so that I can reach you with the
package.

5)  at least attempt to read the documentation.

   Other Stuff:

-   The system is about 150K long/big, so it is split into 4 shar files.

-   The SUID program is separate from the rest of the programs because
it takes a lot longer to run than the rest of the programs.  The
password program takes a while to run, but unless a lot of flags are
turned on, it should be ok.

-   Some of the programs were written by fellow net-landers, some
by me.  I think the only program I am using without the express consent
of the author is the password guessing program, simply because I can't
reach the original author.  I believe it is in the public domain, but
if there is an outcry, I will replace it with another (I like this one,
so for the time being, I'm using it).

   Well, that's it for now.  To get the package, write to:

 dan farmer (that's me)
        at
 df@medusa.cs.purdue.edu

   And I'll attempt to get it to you.  If you don't get it within a
quasi-reasonable amount of time, you can call me at home at:

 (317) - 251 - 9591

   And I'll make the extra effort needed to get it to you.

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

Date: Mon, 21 Aug 89 08:53:12 EDT
From: uunet!harvard.harvard.edu!kiely%lownlab (James P. Kiely)
Subject: suid shell

>o Privileged programs - Programs that grant privileges to users (e.g.,
>  setuid root programs/shells in UNIX) can be exploited to gain
>  unrestricted access to systems.  System administrators should watch
>  for such programs being placed in places such as /tmp and /usr/tmp (on
>  UNIX systems).  A common malicious practice is to place a setuid shell
>  (sh or csh) in the /tmp directory, thus creating a "back door" whereby
>  any user can gain privileged system access.

I don't know if it is common practice but the only "back door" problem
I've had was an suid root copy of /bin/csh in a "lost+found" directory.
This is much more of a problem than a copy in /tmp or /usr/tmp since
the tmp family of directories is wiped clean during reboot.

[ I set all lost+found directories to mode 700 owned by root - neil ]

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

Date: Tue, 22 Aug 89 00:01:28 PDT
From: uunet!Sun.COM!gkass%slapshot.EBay (Gordon Kass)
Subject: SunOS 4.0 security features

>I recall hearing various disparaging things about the C2 stuff and secure
>NFS several months ago, but nothing recently.  So, to those people who are
>using or have tried to use secure RPC and/or the C2 package:
>    o Do they work?
>    o What are the benefits?
>    o What are the disadvantages?

A number of bugs in SunOS 4.0 C2 were fixed in SunOS 4.0.3 and a number more
were fixed thereafter and are available from the USAC (Sun's U.S. Answer Center)
as a patch tape.

Yes, the C2 stuff does work.
Benefits:  if you want C2 security and what that offers, then this is how to
get it.  C2 security primarily offers:
        *  split password files, keeping the encrypted passwords from being
           readable by everyone
        *  auditing, selectable per-user, allowing one to track assorted events
           going on in the system.
Disadvantages:  if you audit a lot of events, it'll take up a lot of disk
space (although you can archive or "rm" as you like) and it might slow down
performance some.

Note that C2 and other levels of Orange Book security are slightly different
than penetration security.  (If this leaves you puzzled, e-mail me for more
details.)

(we did the C2 stuff, along with a lot of other things)

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

Date: Sun, 20 Aug 89 13:10:05 EDT
From: security-request
Subject: Re: Security Holes

sechreset@uther.CS.ORST.EDU writes:
>I am looking for a few programs that will help me tighten up security
>a little bit. . .
>Here is a list of programs that I would like to find:
>A passwd program that forces smart passwds.

Several pd drop-in functions examine passwds for 'goodness'.  I have
them off on floppy here, if they aren't in an available archive I will
forward copies to Neil.  One does some elementary checking (the logical
guesses, etc).  Another (which I really admire the implementation of)
will do some checking on the number of 3-letter valid english runs,
and let you know how many you have.

[ Please send them to me so that I can put them in the archives - neil ]

>A getty that restricts logins only to those that are on an access list

This should not be a function of getty -- it belongs in login.  Imagine
this sequence:

Prog.   Does    User types      Result
=====   ====    ===========     =======
getty   login:  priv_user       Getty finds priv_user on list, invokes login
login   passwd: <wrong passwd>  Login rejects user
login   login:  unpriv_user     Login does not check priv user list
login   passwd: <right passwd>  Unpriv user is now logged in on priv line

>A security audit program that tells you where problems exist on
>a system.

Kochan/Wood describe one of these in their book "UNIX System Security".
I believe a modified (by the author) version was published in Andrew
Burts old list.  Does anyone have an archived copy?  By the by, if you
don't have "UNIX System Security", run do not walk, and get a copy.
It's Hayden Books, ISBN 0-8104-6267-2.  It was $35 in hardback about
two years ago, definately still in print.

[ I am in the process of getting all of the old isis list archives so
  that I can put them in the current archives - neil ]

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

        End of Security Digest Volume 1 Issue 30
        **********************

END OF DOCUMENT