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' #36 not known (1 file, 3490 bytes)
NOTICE: recognises the rights of all third-party works.


Subject: #36 - Unix Security Mailing List


	Admin and new members
	unix security list
	Re: #35 mailing question
	Re: #35 - archives, etc.
	List of common passwords wanted
	the anonymous FTP bug
	Re: DANGER: UUCP *can* propogate the Worm 
	DANGER: UUCP *can* propogate the Worm 
	~uucp/.forward files.
	possible holes
	Re: #35 - Unix Security Mailing List 
	list security


Editors Corner.

Mail seems to be in favor of putting the phage list material into the
archives but integrate the old material from last year into the list

I've asked for a "complete" archive of the phage list (it isn't defunct yet)
and this will go into the archives when I get it.  I'll announce procedures
for getting it at that point (depends how large it finally turns out to be
minus garbage headers, etc.).

For those who don't know, the phage list is the emergency list Gene Spafford
set up when the worm problem started.

Newcomers to the list since last issue:
		Paul Bloch (lll-winken!!paul)

Date: Fri, 11 Nov 88 12:46:04 GMT
From: gatech!!flick	(    Daniel Flickinger     )
Subject: unix security list


    Security can be reasonably broken into two classes: bsd and
    system V.  'flkvax' runs bsd4.2 since software we develop is
    then forward compatible with ultrix and 4.3.  Most of the rest
    of our forty assorted hardware systems are at least System V

    2.1.    it would be of great help if the critical material of
            the list was edited into a single source and made

    2.2     is there a bibliography?

[I tend to think there are so many flavors of Unix that a strict partition
into the two categories would leave a lot of systems and topics in the middle.
A problem with one flavor may or may not show up in another, and it certainly
doesn't hurt to have future problems addressed before one encounters them.

Regarding 2.1/2.2, I don't have time to wade through editing -- any
volunteers?  Or for compiling a bibliography?]

Date: Tue, 15 Nov 88 12:25:34 EST
From: grymoire! (Bruce Barnett)
Subject: List of common passwords wanted

I am trying to improve security at my site, and have been
checking the password files for "common" passwords.
I have used
	The list in the Unix-Security archives
	Telephone database for firsat names

Does anyone have a list with words not found in  /usr/dict/words.
I am looking for a list of
	first names
	Fictional characters (SF, Comics, Literary, etc.)
	Sports Teams
	phrases (wysiwyg, tanstaffl)
I have programs to check passwords BEFORE encrypting them. I would
like to check encrypted passwords also.
Bruce G. Barnett  <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP>

Date: Sat, 19 Nov 88 01:53:49 EST
From: Theodore Ts'o <>
Subject: Re: DANGER: UUCP *can* propogate the Worm 

   Date: Fri, 18 Nov 88 12:06:16 PST
   From: ames!!csg@EA.ECN.PURDUE.EDU (Carl S. Gutekunst)
   Reply-To: ames!!csg@EA.ECN.PURDUE.EDU (Carl S. Gutekunst)

   I admit to being less concerned about what local users could do than
   what an outsider could do. Pipes are obviously useful both to outside
   crackers and to inside tomfoolery, even if it only gives permission
   as user "daemon" and group "other"; that's why I posted the patch to
   remove it in my original posting. 

"Only" as user daemon?  Do a quick check of who owns and has write
access to /usr/spool/at.  So if RTM had been clever, his virus could
have cracked root on most machines, and it could have done so many
interesting things.  (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.)  

I've changed /usr/spool/at to be owned by root and changed atq, atrm,
and at to be setuid root instead of daemon.  This is probably a good
thing to do, since if you can spoof at, it's all over but the shouting.

						- Ted

Date: Sat, 19 Nov 88 14:10:05 EST
From: "Robert L. Krawitz" <>
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?  One for syslog, one for sendmail, one for at,
etc.  It's possible to go overboard with this sort of thing, but even
100 extra users (which seems the better part of an order of magnitude
more than would be needed) in the passwd file is completely irrelevant
for any medium sized site.  I don't particularly care for at to be
setuid root, given the number of people who like to hack it locally
(not at my current site, though) and botch it (for example, someone
once came up with an "at reboot" hack to allow people to run things
when the system reboots -- they were lazy and it took me all of 30
seconds to see how to break it and a minute more to type in an
example, and I'm not very good at these things).

UID's are cheap.  Overloading them in a way that compromises security
is a lose.

I'm aware that some kernels have restrictions in the number of active
UID's (licensing bogosity).  I don't have a good answer for these
cases, other than to try to get rid of these sorts of restrictiosn by
pressuring vendors.  Berkeley moved one step in the right direction in
4.3; the trend toward using more UID's and GID's for security purposes
has a long way to go.

harvard >>>>>>  |		Robert Krawitz <>
bloom-beacon >  |think!rlk
topaz >>>>>>>>  .		rlk@a.HASA.disorg

Date: 19 Nov 1988 15:20 EST
Subject: ~uucp/.forward files.

.forward should always override (/usr/lib/upas/namefiles|/usr/lib/aliases) for
real people (non-system accounts).  what a person does with their own mail is
their own business.

control over the type of .forward service is supported for classes of accounts
sounds useful, though.


Date: Tue, 22 Nov 88 09:36:19 pst
From: John Sechrest <>
Subject: list security

I am all in favor of developing an encryption scheme that would 
encrpt the mail and allow it to be secure thru the whole transmission
process. Something like the secret mail program would be fine.

[For users with secret mail (or any mutually agreeable encryption algorithm)
why not just make some scripts for "<crypt cmd> | uuencode | mail" etc.?
I don't see that we need yet another encryption system unless it offers
better security than what we have.

As for encrypting the security list, I have doubts about the utility...
Getting passwords sent out presents the same problem.  Early on in the list
it was felt that encryption would just be a hassle.  If there are strong
feelings that this should be re-examined let me know...]


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