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' #30 1987-04-24 (1 file, 5464 bytes)
NOTICE: recognises the rights of all third-party works.


Date: Fri, 24 Apr 87 19:12:14 EDT
Subject: # 30 - Security Mailing List


        Admin and new people on the list
        A fix to the password checker
        Security of this list
        True security risks
        Re: Unix userid conventions
        Re:  Security Mailing List, # 25
        Security hole in Masscomp RTU 3.1


Editor's corner.

Sorry to be so long about this but I've been struggling to work around
the seismo-duplication problem that was sending people up to four copies
of the list.  Not an efficient use of phone time.  Most of the list
used to be stored at seismo to which I mailed one copy; seismo's sendmail
thought the list was too large (about 6Kbytes) and gagged.  I don't know
*why* it was stored at seismo other than that's the way it was when I
got it.  In my copious spare time I've revised things so the list is now
kept on my home system and mailed from here but without sending one copy
per person.  If anyone gets a duplicate of this message let me know.

Newcomers to the list since last issue:
        David H. Brierley (root@rayssd)
        Pete Cottrell (pete@mimsy)
        E. V. Parker (evp@atssc)
        Gorodecki Tom (nsta!tom@nsc)
        Jan Wortelboer (janw@uva)
        Eric Carroll (emc@unicus)
        A. Walker (
        Roger D. Roles (rdr@alliant)
        Joe Pato (pato@apollo)
        Sam McCall (samccall@ucdavis)
        Jack Herrington (umbio!jherr@gould)
        Scott Boake (boake2!scott@jc3b21)
        Yves Devillers (devill@inria)
        Alan R. Bull (bull@nrl-css)
        Edward Rynes (rynes@cwruecmp)
        Chuck Cameron (ccameron@dsacg1)


Date: Sun, 15 Mar 87 13:01:36 CST
From: pyrchi!numusic!nucsrl!gore (Jacob Gore)
Subject: A fix to the password checker

There is a problem with the way the password checker (which was in the first
half of the #23+#24 issue) handled words in the geicos field ("-g" option).

Since only blanks were treated as delimiters, commas in the field got attached
to the words.  Thus, it would try to guess things like "Lastname," and

The fix, basically, involves using both a space and a comma as word
delimiters.  The patch to do this follows.

(It also changes ARB_CONST from 5 to 20, so you may want to change that back to
5, or to some other constant.)

Jacob Gore
Northwestern University, Computer Science Research Lab
*** pwcheck.c.old       Sat Mar 14 16:46:31 1987
--- pwcheck.c   Thu Mar 12 14:08:05 1987
*** 195,202 ****
! #define ARB_CONST       5
--- 195,224 ----
! /*
!  * Added by Jacob Gore, March 12, 1987.
!  *
!  * Finds the pointer of the leftmost occurance within the character string
!  * 'string' of any character found within the character string 'chars'.
!  *
!  * If none of the characters in 'chars' appear in 'string', NULL is retutned.
!  *
!  */
! char *
! indexm (string, chars)
!     char *string, *chars;
! {
!     while (*string) {
!       if (index(chars, *string) != NULL) {
!           return string;
!       }
!       string++;
!     }
!     return NULL;
! }
+ #define ARB_CONST       20
*** 280,286 ****
                *cp2 = '\0';
            for (;;) {
!               if ((cp2 = index(cp, ' ')) == NULL) {
                    if (uandltry(pwd,cp))
--- 302,309 ----
                *cp2 = '\0';
            for (;;) {
!               /* use both ' ' and ',' as delimiters -- Jacob */
!               if ((cp2 = indexm(cp, " ,")) == NULL) {
                    if (uandltry(pwd,cp))


Date: Sun, 15 Mar 87 13:03:45 CST
From: pyrchi!numusic!nucsrl!gore (Jacob Gore)
Subject: Security of this list

While trying to mail the patch to the password checker, I got to think about
the distribution of this list.  If this has already been discussed, I'd
uppreciate if somebody could summarize the outcome of the discussion.

Admission to this list is (relatively) well-controlled.  The sites that
receive it are known to the moderator, and so is the name of the person
responsible for seeing who gets access to the list at the site.

But what about the sites along the UUCP path from isis?  Last I checked,
SECURE was not one of cost options for pathalias (:-).

If we're going to be serious about controlling who gets this list, shouldn't
we be using some sort of encryption/decryption?

Jacob Gore
Northwestern University, Computer Science Research Lab

[See the early archives.  The decision made was that any scheme involving
passwords would be too costly in terms of time and that passwords would
leak out anyway.  Certainly they couldn't be e-mailed, and I have neither
the financial nor temporal resources to call every new member long distance.
Instead, we're relying on the ignorance factor -- that the sites this passes
though don't scan the mail as it goes by...]


Date: Mon, 16 Mar 87 15:36:58 est
From: seismo!vax135!hoh-2!whb (Win Bent)
Subject: True security risks

The following appeared in comp.unix.wizards.  I found it
enlightening, in the sense that it pointed out things which
I "knew" but do not often think about.  I thought it worth
passing along to the Security mailing list.

Sorry about including the ENTIRE header, I was afraid of
deleting pertinant/important information.

Wilson H. Bent, Jr.             ... ihnp4!hoh-1!whb
AT&T - Bell Laboratories        (201) 949-1277
Disclaimer: My company has not authorized me to issue a disclaimer.

>From homxb!houxm!ihnp4!ptsfa!lll-lcc!ames!cit-vax!usc-oberon!sdcrdcf!otto!jimi!asci!brian Tue Mar 10 18:32:41 1987
Article 1305 of comp.unix.wizards:
Relay-Version: version B 2.10.1 6/24/83; site vax135.UUCP
Path: vax135!homxb!houxm!ihnp4!ptsfa!lll-lcc!ames!cit-vax!usc-oberon!sdcrdcf!otto!jimi!asci!brian
>From: brian@asci.UUCP (brian)
Newsgroups: comp.unix.wizards
Subject: Re: Unix userid conventions
Message-ID: <124@asci.UUCP>
Date: Tue, 10-Mar-87 18:32:41 EST
Date-Received: Thu, 12-Mar-87 17:13:14 EST
References: <4788@brl-adm.ARPA>
Reply-To: brian@asci.UUCP (BRIAN DOUGLASS)
Organization: Applied Systems Consultants, Inc.  Las Vegas
Lines: 60
Summary: There is a time and place for cryptic userids


Our company does a large amount of consulting & programming on systems from
PC's to IBM main frames, with 90% of the work under Unix, which is divided
up about 70-30 between DoD and Private enterprises.  Every system can be
considered to contain sensitive information to somebody somewhere, whether it
be government or private.  Generally speaking, under Unix using the user's
name is the only good method for userids for the many reasons already
mentioned (i.e.  e-mail), and most large systems do generate their own account
names for their own convenience. However, there are times and systems when a
cryptic password, and/or userid is necessary.

When a name is used for the userid, and the user is allowed to assign their
own password, 90% of the time they will use passwords of some familiarity,
their child's name (alla Wargames), religious affiliation, names of great
ships.  For a great many systems this is no problem.  But in large corporate
structures, the most pervasive security issue facing Administrators today
arises using such a passwording and userid scheme.  This is the Internal
Infiltrator (I.I.).

These security violator, under Unix particularly, usually have no interest
getting to the master account (root).  Rather, the I.I.  is usually interested
in viewing data he has no business looking at.  For example, a manager writes
a confidential memo to another manager that a recently transfered employee was
suspected of using cocaine on the job, and for the new manager to keep an eye
on him.  Later the employee is fired for whatever reason, only to produce a
copy of the memo.  Legally explosive.  Other examples include viewing a
competitor's accounting files.  An unscrupulous colleague damaging your work
for his own gain in the work place.  These have and continue to happen in the
corporate world, and if an I.I.  knows something about you, and your method
for passwording, he's already cut down the number of password bangs from
hundreds of thousands to tens, or maybe even a few thousand.  He probably
doesn't even care about root's password.  The I.I.  is the #1 threat to
security in the corporate Unix world.

For those situations our method of generating a password is to open a
dictionary, point to a word, and take the first letter.  Then close the
dictionary, open again, p-t-a-w, and take the second letter, etc., etc.,
through the maximum allowable characters.  From, there, it is absolutely
forbidden to write down the password, instead a mnemonic is developed (i.e.
qazxsw is quite all zebras x-ray session writing).  This is drilled into the
user.  We now are back to hundreds of thousands of possibilities.

Under Unix, it makes no sense to be cryptic for the userids, for all the I.I.
would have to do is print the passwd file, and then bang on the password to
get in under the account desired.  Using mnemonic userids is the only viable
method to assign these.  However, on non-Unix machines, without these types of
security deficiencies, cryptic userids do become a powerful tool for internal

Lastly, the best security method of all is put the system in a TEMPEST
approved vault, with all the terminals in the vault, and make everybody sign
in and out.  But then again, anybody that really wants in can always pull out
the most trusted tool of any system penetrator.  The time honored practice of
bribery.  A very hard method to defend against.

Brian Douglass
Applied Systems Consultants, Inc. (ASCI)
P.O. Box 13301
Las Vegas NV  89112
(702) 733-6761


Date: Mon, 16 Mar 87 10:00:18 mst
From: Alan Silverstein <hplabs!hpfcla!hpfcdt!ajs>
Subject: Re:  Security Mailing List, # 25

Thanks for taking charge.  One hot topic I'm sure will start to come up
more often is commercial vendors rising interest in meeting the government's
Trusted Computer System Evaluation Criteria (TCSEC, aka. the Orange Book).

Alan Silverstein, Hewlett-Packard Systems Software Operation, Fort Collins,
Colorado; {ihnp4 | hplabs}!hpfcla!ajs; 303-229-3053; (lat-long on request :-)

[So, what work has been done in this area w.r.t. Unix?]


Date: Sun, 22 Mar 87 14:35:43 PST
From: David Robinson <seismo!elroy.Jpl.Nasa.Gov!david>
Subject: Security hole in Masscomp RTU 3.1

This is what I consider a security hole in Masscomp's handling
of setuid files.  Masscomp RTU is a SYSV derived kernel with
4.2bsd support on top. I don't know if this is a generic
SYSV problem but it doesn't occur a Sun (4.2bsd) system.

Create a file with either mode 4775 or 4777.
% chmod 4775 file
Login to an account that is in the same group or world.
% cp /bin/csh file
% file
Now you have a csh that is running setuid to the owner of the file!

I see two problems here:
1) You should NEVER have setuid files writeable to anyone but the
2) MAJOR bug in Masscomp RTU 3.1 that allows NON-ROOT users to change
   a file without clearing the setuid bit!!

                -David Robinson


                        The UNIX Security Mailing List

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