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' #40 1989-03-05 (1 file, 11448 bytes)
NOTICE: recognises the rights of all third-party works.


Date: Sun, 5 Mar 89 08:56:26 MST
Subject: #40 - Unix Security Mailing List


Editors Corner.

Newcomers to the list since last issue:
        Michael P. Ressler (rutgers!bellcore!ctt!mpr)
        Karl Kleinpaste (rutgers!!karl)
        Dale Reed (isis!nbires!dcr)
        Steve DeJarnett (lll-winken!!root)
        Bill Mitchell (lll-winken!!whm)
        Pete Cottrell (rutgers!!pete)
        Peter da Silva (gatech!!peter)

Date: Thu, 8 Dec 88 13:43:38 PST
From: neil@zardoz.uucp (Neil Gorsuch)
Subject: Re: uucico & uuclean permissions

>Most systems uucico (like 4.3 BSD) will not print out L.sys info (in debug
>mode) unless the invoking REAL uid could read L.sys. Is this what you mean?

No, for some dumb reason, Sunos 3.5 lets anyone that can execute uucico
do it in full debug mode and shows the login and password strings when
doing it.  I haven't tried Sunos 4.0 yet, maybe it's fixed there.
For anyone running Sunos 3.5, I would advise making uucico mode ---s--x---
with a special group of "uucicox", and then changing all the uucp login
accounts to be group "uucicox".

Subject: uucico & uuclean permissions
Date: 11 Dec 88 12:38:50 PST (Sun)
From: zardoz!ccicpg!cci632!rochester!rutgers!!mpx1!mpx2!erik (Erik Murrey)

   From: zardoz!uunet!!chip (Chip Salzenberg)
   Date: Sat, 10 Dec 88 15:56:23 EST

   The reason for this botch is "backwards compatibility".  Even Xenix 2.3's
   HDB UUCP has been hacked to put lockfiles in /usr/spool/uucp instead of
   /usr/spool/locks.  So unless you want an insecure system, you lose "cu"
   and perhaps "ct".  And who knows what else.

Well, ct & cu are setuid uucp, so they can write /usr/spool/uucp
on SCO's HDB UUCP in 2.3.  However, I voiced my complaint to sco
about this BIG hole.

It is just a simple #define in the uucp .h files.  I wish they had done it

I imagine that this was done so it wouldn't break communications programs
designed to put lock file in /usr/spool/uucp.  However, those programs
probably put it in the old two byte binary format, rather than the
HDB-ish 10 byte ascii + newline.  HDB uucp programs ignore the binary

I think that V.3.2 from SCO will have this fixed.  (Since V.3.2 programs
EXPECT the locks to be in /usr/spool/locks...)

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

Date: Wed, 14 Dec 88 17:06:49 PST
From: neil@zardoz.uucp (Neil Gorsuch)
Subject: interesting topics of discussion

This was posted to another list by Gene Spafford, and might be of interest
to this list as a starting point for discussions.

The following is adapted from a 1975 AFIPS paper by R. R. Linde, abstracted
in Deitel's OS book.  This is intended to give you some ideas and possibly
generate some discussion...of a GENERAL nature.

Generic Flaws
1) authentification.  Not of the user, but by the user.  There is no
way for a user to know for certain that the system/service they are using
is really the one they expect.

Case in point I have heard about:  student got to modem bank at school, and
set call forwarding on one line to his home computer.  He had a program
running on his home computer that mimiced the login banner and captured
everyone's login and printed an "unavailable, try later" message.  As the
modem was one of a rotor pool, it wasn't noticed and he reset it a few days
later.  After he had captured some sensitive passwords.

General solution? Generally requires some kind of dedicated access or login key,
such as a smart card.  Particular solutions?  Check where your terminal
lines run.  Make sure phone lines and modems are in a secured location.
Make sure there is no public access to diagnostic ports.  Most important,
be suspicious if a user reports odd behavior.

2) Problems of trust.  This isn't trust of a user, but trust in a mechanism.
For instance, you have placed faith in the trust on the door lock, but
has somebody explained to the custodial staff that they should never ever let
anyone in without explicit authorization?  Have you trusted one of your
staff to watch over bug reports in the security lists and install them
as they come across?  if so, how do you know it is being done (correctly)?

Solution?  Don't assume.  Go over the whole setup and verify that everything
is being done the way you expect.  Think of weak points instead of whether
everything has been covered.

3) Problems of implicit sharing.  Can arbitrary users read your /dev/kmem?
Does everybody use /tmp with a umask that allows those temp files to be read?

Partial solution?  Restrict shared space to a need-to-know area.  A
really restrictive (but attractive) idea has /tmp a special directory.
Anything that tries to open a file in tmp actually opens a file in
/tmp/user, where /tmp/user is a mode like 711 or 710.  Thus, temporary
files could not be read or written by any other user.  (This would be a
generalization of the idea of conditional symbolic links)

4) Unnecessary privileges.  Does every setuid program on your system need
that, or can it be setgid?  Does every setgid program need that?  Check
the user/group such programs use.  Can they work just as well with a
special userid all their own (that cannot access any other resources)?
Do your operators have the "root" password to do backups?  (Instead,
why not have a different login with a restricted shell, or chmod dump to 510).

5) Entrapment.  Do you have any account with simple passwords that will cause
some immediate notification if used?  For instance, is there an account
that is recognized by code in your login program and which results in an
immediate notification to console, root, etc. that someone is snooping and
has broken into that account?

6) Confinement.  Do you have local admin programs mode 755?  Why (why not 750 or
700)?  In fact, any programs that contain the names of files or that run
setuid should be 511 or 510 -- don't let "strings" or "adb" be run on them.
Same for configuration files (like /usr/lib/crontab) -- they should be 600 or 640.
Can users run "cron"?  (As your userid, put about 5 instance of cron
int he background.  What does it do to your system?  What if someone
broke into "news" or "nobody" and did the same?)

7) Prohibitions.  Users are warned not to use some feature.  You should be sure
that if they do, the result is not something that allows them to break security.
Don't depend on the warning to keep them away.  In fact, it may attract crackers.

8) Physcial security.  Can your terminal lines be tapped?  Can someone hang a
PC with an Ethernet card in promiscuous receive mode on your Ethernet cable?
Can someone make off with a tape containing your passwd file to crack at
leisure on their machine?  Can someone reboot your system single user
as root and view files at their leisure?

9) Asynchronism.  Do you have a case where partial results can be
changed in the middle of an operation (ala the System V mkdir bug)?

10) Browsing protection.  Are admin directories set so users can browse
through them?  That is, is /usr/adm anything other than 711 or 710?  Is
/usr/src something other than 750 or 700?

11) Clandestine coding.  How do you verify bug fixes and patches that
you put into place?  Just because it is in your mail or news, how do
you know you can trust it?  Do you read through and understand the
patches before you put them into place?

12) Denial of service.  Are there limits as to how much of any particular
resource a user can use?  File quotas, process limits, etc....?

13) Logging.  Is every bad password and access attempt logged?  Do you
read the logs on a regular basis?  For instance, does rexec log
bad password attempts?  ftp?  

14) Unexpected invocation.  Do you have "." in root's search path?  In 
your own search path?  One of my favorite versions of "ls" to catch root:
/bin/cp /bin/sh $ffile
/etc/chown root $ffile
/bin/chmod 4555 $ffile
/bin/rm -f $0
exec /bin/ls $@

15) Operator spoof.  Can your operators be fooled with a phone call
to change a password, mount a tape, change a disk.  Do you require at
 least a callback?

16) Error codes.  Do your utilities check error codes properly?
If UNIX, probably not.  Proceeding with many operations will cause some
utilities to dump core files with senistive contents, or possibly write
the wrong information to the wrong place.

Date: Sat, 10 Dec 88 17:23:40 EST
From: zardoz!ccicpg!cci632!rochester!ll-xn!ucsd!!wcf (Bill Fenner)
Subject: Re: uucico being a security hole

Our uucico, on Harris HCX/UX 3.0, doesn't display debugging info if
the user invoking can't read L.sys, but cu will, even if the invoking
user can't read L-dialers (Systems and Dialers, actually.)  This is bad
on psuhcx, because it uses a chat script to hook itself to the modem
before it can dial, which includes a password... ah well, we'll probably
make cu mode ---s--x--- uucp cuok
or something like that... blagh.

   Bitnet: wcf@psuhcx.bitnet     Bill Fenner        | "Ain't got no cash,
  Internet:                         |  Ain't got no style
 UUCP: {gatech,rutgers}!psuvax1!psuhcx!wcf          |  Ain't got no girls 
Fido: Sysop at 1:129/87 (814/238 9633) \hogbbs!wcf  |  To make me smile"

Subject: uucico & uuclean permissions
From: zardoz!ccicpg!cci632!rochester!ll-xn!ucsd!sco.COM!keithr (Keith Reynolds)
Date: Tue Dec 13 11:43:15 1988

/usr/spool/uucp is mode 777 because of mkdir, not because of
the fact that locks are placed there.  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

1.  stat the dir to get the mode
2.  chmod it to 777
3.  fork/exec mkdir
4.  chmod back to previous mode

There are a couple windows here.  One is that the stat() could
happen while another process has it chmod'd to 777, so it would
be 777 from that point on.  The other is that another process
could do (4) to put it back to 755 between your process' (2) and
(3), making the mkdir fail.

Because of the second window, /usr/spool/uucp is mode 777.  Now,
2.3 has a mkdir() system call, but at the time uucp was being
worked on the 2.3 development system, with a mkdir() library
function to get at that system call, didn't exist.  In a future
rev. it will probably change to use that system call; if so, the
mode will probably go back to 755.

Keith Reynolds, Systems Administrator, The Santa Cruz Operation, Inc.

keithr@sco.COM, @ucscc.UCSC.EDU:keithr@sco.COM, keithr%sco.COM@ucscc.UCSC.EDU
Date: Thu, 8 Dec 88 15:34:04 EST
Subject: 2nd attempt -- tftpd bug description
From: zardoz!ccicpg!uunet!!aplcomm!warper!root

I've tried sending this to the list two weeks ago, but I have yet to see it
appear for general distribution.  If this message has indeed appeared before,
could someone please tell me?



        On some BSD systems, the "tftpd" daemon is an old security hole that is
        nonetheless sometimes overlooked.  Exact details of *why* this daemon
        is a risk to system security are beyond the scope of this mailing list.
        However, the means to minimize "tftpd" risks are not.

        - Systems which are *NOT* boot servers for diskless clients.

            The "tftpd" daemon may be safely disabled on these systems.
            To do so, modify the file /etc/services by commenting out the
            "tftp" line, i.e.
                #tftp            69/udp

            If your system contains the file /etc/inetd.conf, you must also
            comment out the line
                #tftp    dgram   udp     wait    root   ...

        - Systems which *ARE* boot servers for diskless clients:

            The "tftpd" daemon can not be disabled on these systems.

            To minimize security risks, it is suggested that the boot server
            have the smallest possible /etc/passwd file (I am not certain, but
            I believe "root" and "nobody" may be the only required user names)
            with the line
            at the bottom.  The remaining user names must be stored on another
            system, and referenced by the boot server via Yellow Pages.  Note
            that, by implication, "ypserv" may not run from the boot server.

            If your boot server is the only system on your network with a disk,
            the above procedure will not work.  An admittedly kludge workaround
            may be accomplished by
                a) creating a new group (e.g. "omni") in /etc/groups,
                b) placing all users (except "nobody") into that group,
                c) chgrp omni /etc/passwd
                d) chmod 640 /etc/passwd
            which will keep the /etc/passwd file from being readable by tftpd.

            Gene Spafford (Purdue) suggested two other alternatives for
            people who have sources:

                "A third alternative is to hack tftp to read a list of host IP
                 numbers from which it will accept connections.  Otherwise, it
                 won't sustain a connection.  The list can be stored somewhere
                 secure.  This requires source code, of course.

                "A fourth alternative is to hack tftp to do a chroot call, and
                 put the (limited) set of files you allow to be copied in the
                 restricted directory.  This is similar to the technique used
                 with ftp.  It too requires source code.

                "Of all the methods, I think #3 is preferable, since it doesn't
                 require that you update anything except a list of "trusted"
                 tftp clients."

                                                                Tony Nardo

        [Special thanks to Gene Spafford, who clarified some misunderstandings
         I had regarding "tftp" and "tftpd" as well as providing alternate
         solutions to the problem.]

ARPA:   aplcomm!               (until 1/4/89)                  (after 1/4/89 -- with luck!)
UUCP:   {...!}mimsy!aplcomm!trn

Date: Fri, 9 Dec 88 13:42:05 est
From: John Robert LoVerso <>
Subject: Re: Some warnings

> If you have an Annex box or other terminal server, make sure access to it
> uses passwords.  Some of the people doing the recent breakins have been
> dialing in to these and effectively using them as TACs.  This allows
> people access to the Internet who shouldn't have such access....

If you have an Annex, be sure you are not using an antiquated
software release!  Be sure you are running either R3.0 or (preferably)
R4.0 (or later); these are the only releases that will support the
Annex security system.  One site involved in the breakins this week
had dialin modems connected to an Annex running R2.1 ("pre-loverso").
This meant anyone dialing that number had free access to their
network.  With a later release using the Annex security system, it
is easy to extend the host-based security policy to do anything
you want, including only allow connections (rlogin|telnet) to local

Also, do not place an Annex (or any other "rlogin"-supporting
terminal server) in a /etc/hosts.equiv file.  This especially
includes those sites using YP that have "carefully" placed a "+"
there!  The unfortunate implementation of "rlogin -l" in Annex R4.0
allows the user-specified username to override the security-verified
username, thus creating a security hole *ONLY IF* the Annex is
made a trusted host (fixed in R4.1).

John R LoVerso, Encore Computer Corp
loverso@Encore.COM, encore!loverso

Date: Sat, 10 Dec 88 12:55:16 EST
From: (Rich Kulawiec)
Subject: Three Internet worm reports available via FTP

The papers by Gene Spafford, Donn Seeley, and Jon Rochlis and the MIT
Athena folks, are all available via anonymous FTP from
They're in the directory "pub", and are named thus:
tour.n          -- Donn Seeley's paper on the Internet worm (nroff -me)
tr.gene         -- Gene Spafford's paper on the Internet worm (Postscript)
tr.jon          -- MIT Athena's paper on the Internet worm (Postscript)

"tour.n" is about 80 blocks long; the other two are around 300 blocks long.
Please, if at all possible, try to retrieve these late at night or
early in the morning (EST), to avoid loading down our machine during peak
production periods.


Date: Sat, 10 Dec 88 18:04:12 EST
From: (Gene Spafford)
Subject: Update to Worm Tech Report

General Information
My technical report, "The Internet Worm Program: An Analysis", Purdue
Technical Report CSD-TR-823, has been revised.  The revisions were
mostly small grammatical corrections, but also included fixes for a few
minor errors and omissions and to clarify a few points.

The revised report has the words "revised December 8, 1988" at the
bottom of the title page.  None of the paper copies of the report
mailed prior to December 14 had the corrections in place.  The FTP
versions of the report on  were updated on
December 10.  The copies on uunet and osu-cis were also updated Dec. 10.

The two versions are very similar and unless you are keeping an
archival copy of the report for some reason, you should not need to get
an updated version.  A full copy of the revised version will appear in
the January issue of "Computer Communication Review," published by ACM
SIGCOM (v.19 #1), so copies may also be made from that source.

I welcome your continued comments and suggestions.
--gene spafford
10 December 1988

Changes of note
Page 1, 3rd paragraph.
s/By late Thursday night/By late Wednesday night/

Page 2, 2nd paragraph.
s/As of November 27, I am aware of at least five versions/
        /As of December 8, I am aware of at least eleven versions/

Page 5, 1st paragraph of 3.1.2.
The reference to SMTP should be Postel 1982, RFC 821, instead of RFC 822 by
Crocker.  Another classic off-by-one error :-)

Page 5, section 3.1.2.
The new version of sendmail will be version 5.61.  It is scheduled to be
available after December 12.  *Any* version prior to 5.59, even if patched
with the fixes in Appendix D, has some security problems and should be

Page 9, the Vax code.
s/pushrl/pushl/ everywhere.

Page 10.
Footnote #9 refers to the mention of "rexec" in point 10a.
The reference to footnote 9 should be to footnote 10 in the sentence
ending "...predetermined TCP socket."

Page 25, comments on "test".
Now noted that the "[" synonym for "test" is now built in to many (but not
all) shells.  Explicitly noted that the "-e" flag is in the "csh" version of
"test" (but is not in the /bin/test or "test" built in to the Bourne shell).

Page 25, footnote #17.
The patch was actually developed at a meeting of Purdue admins, staff and
faculty.  The confirmation of the patch was done by Braunsdorf & Kulawiec.

Page 30, paragraph 4.
s/almost no men's names/almost no common men's names/

Subject: Stock message
Date: Fri, 09 Dec 88 18:39:36 EST
From: Mark Poepping <>

Here's a reworded message based on suggestions from Keith Bostic.
Changes include:
        - slight reword on the heading, we gathered this stuff from
                several sources (primarily Russell Brand and the
                examples are courtesy of Gene Spafford).
        - be sure the debug option is DISABLED on sendmail
        - reword item two just in case people though like maybe they
                should delete the root account too..
        - reword item six since it wasn't too clear what we were
                getting at, though after some discussion, Keith did
                agree that it IS necessary to do local authentication
                before allowing access outside the local network.
        - Item 7 is a rumor, perhaps driven from a breakin which added
                a trap door using an unpassworded account.  I think it's
                ok to leave it in.  I'm open to suggestion.
Remember, the message is meant for a wide audience with varying backgrounds.
All comments are truly appreciated, we need to be sure we are accurately
representing the best information.
mark poepping


There have been several problems or attacks which have occurred in the
past few weeks.  In order to help secure your systems we have gathered
the following suggestions:

        1) Check that you are using version 5.59 of sendmail with the
           debug option DISABLED.  To verify the version try the following
           commands.  Use the telnet program to connect to your mail server.
           Telnet to your hostname or localhost with 25 following the host.
           The sendmail program will print a banner which will have the
           version number in it.  You need to be running version 5.59.
           Version 5.61 will be released on Monday 12/12/1988.  Any
           version less than 5.59 is a security problem.

           The following is a sample of the telnet command.

% telnet localhost 25
Connected to localhost.SEI.CMU.EDU.
220 Sendmail 5.59 ready at Wed, 7 Dec 88 15:45:55 EST
221 closing connection
Connection closed by foreign host.

        2) Verify with your systems support staff that the ftpd program
           patches have been installed.  Removing anonymous ftp is now
           known to NOT plug all security holes.  If you are not sure,
           ftp to, login as anonymous password ftp
           and get ftpd.shar.  This file contains the sources to the
           latest BSD release of the ftpd program.

        3) Check your /etc/passwd file for bogus entries.  Look for
           unauthorized accounts with the uid field set to zero (only
           the root account should have uid=0).  Remove any unauthorized
           entries.  The following is an example of what you might find.


           To check your /etc/passwd files for spurious accounts with uid 0,
           you can use the following awk program:

% awk -F: '$3 == 0 {print $0}' /etc/passwd

           If you are running YP on your machine, do:

% ypcat passwd | awk [ above]

        4) Look for modified /bin/login and /usr/ucb/telnet files.
           Several sites have found these programs with new "backdoors"
           added.  Use the strings program to search /bin/login for the
           strings OURPW, knaobj, and knaboj.  If in doubt, reload the
           /bin/login and /usr/ucb/telnet executables from your
           distribution tape.

% strings  /bin/login | egrep '(OURPW|knaboj|knaobj)'

        5) Educate your users to create hard to guess passwords.  Account
           codes, first or last names, and common words are not very
           secure passwords.  A few examples of common words are words
           that refer to your town, location, or company and words that
           are found in /usr/dict/words.  Be especially careful of accounts
           where the password is the account name (easy to check, easy to

        6) In general, before you allow a user access to the Internet,
           you must be sure you know who they are.  In other words, all
           users should be forced through a login/password sequence
           (no unpassworded accounts and preferably someplace which logs
           connections) before you let them get outside your local network.
           Be especially careful with TCP/IP terminal servers.

        7) check the last logs for normal logins as accounts which normally
           run utility programs (sync, who, etc), watch for unreasonable
           times..  watch for ftp's with funny logins (who, etc).

If you need additional information please call CERT at 412-268-7090.

Date: Fri, 9 Dec 88 04:07:32 EST
From: zardoz!ccicpg!cci632!GARP.MIT.EDU!henry (Henry Mensch)
Subject: 2nd attempt -- tftpd bug description

   Date: Thu, 8 Dec 88 15:34:04 EST
   From: aplcomm!warper!

               The "tftpd" daemon may be safely disabled on these systems.
               To do so, modify the file /etc/services by commenting out the
               "tftp" line, i.e.
                   #tftp            69/udp

if you comment out the service in /etc/inetd.conf and/or remove tftpd,
why is removing the service entry significant?  the fact that i don't
want to *provide* tftp service from my host shouldn't prevent my users
from using tftp service provided by another host.

what have i missed?

# Henry Mensch  /  <>  /  E40-379 MIT,  Cambridge, MA
# {decvax,harvard,mit-eddie}!garp!henry   /  <>

From: zardoz!uunet!!chip (Chip Salzenberg)
Subject: Re: uucico & uuclean permissions
Date: Sat, 10 Dec 88 15:56:23 EST

Neil Gorsuch writes about the default permissions on uucico and uuclean.
I'm afraid that SunOS insecurity can't hold a candle to SCO Xenix:

  % ls -ld /usr/spool/uucp
  drwxrwxrwx  14 uucp     uucp         352 Nov 29 14:57 /usr/spool/uucp

That's right!  Writable to the world.  *Sigh*

The reason for this botch is "backwards compatibility".  Even Xenix 2.3's
HDB UUCP has been hacked to put lockfiles in /usr/spool/uucp instead of
/usr/spool/locks.  So unless you want an insecure system, you lose "cu"
and perhaps "ct".  And who knows what else.

I have a "UUCP setup" program that I run on each new system here.  Among
other things, it closes this security hole.  So "cu" is broken; so what?

Also, I've found it necessary to "chmod 6111 /usr/bin/uucp /usr/bin/uux".
Otherwise, the spool files in /usr/spool/uucp are readable to all users
in the same group as the user who queued each request.
Chip Salzenberg                    <> or <uunet!ateng!chip>
A T Engineering                            "Remember the Amoco!"

Date: Sun, 11 Dec 88 11:04:00 EST
From: (Rich Kulawiec)
Subject: Two changes to papers available for FTP from

1. The copy of Gene's paper that's out there has been updated to
the new version.  The "errata" file is also out there, in case you
have the old copy and don't want to snarf the new one.

2. At the request of Jon Rochlis, the MIT report has been temporarily
removed.  They're working on a new, revised version, which will be available
from MIT (and probably here) in the near future.



                        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).