The 'Security Digest' Archives (TM) |
|
About |
Browse |
Search |
Acknowledgments |
Contributions |
Feedback Help | Index | Search | Contact | Notices | Changes |
ARCHIVE: Unix 'Security Mailing List' - Archives (1984 - 1987)
DOCUMENT: Unix 'Security Mailing List' #37 not known (1 file, 22864 bytes)
SOURCE: http://securitydigest.org/exec/display?f=unix/archive/037.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
Subject: #37 - Unix Security Mailing List
Topics:
Admin and new members
uucico & uuclean permissions
Re: (relatively) secure unshar?
Re: uucp security hole and fix
Re: report on the Internet Worm
report on the Internet Worm
report on the Internet Worm
.forward vs aliases
Re: DANGER: UUCP *can* propogate the Worm
Re: DANGER: UUCP *can* propogate the Worm
Re: ~uucp/.forward
Re: ~uucp/.forward
Re: ~uucp/.forward
DANGER: UUCP *can* propogate the Worm
UNIX security
Re: .forward vs aliases
Re: ~uucp/.forward
Re: ~uucp/.forward
minimizing the risks of tftpd
Re: ~uucp
Re: ~uucp/.forward
the good of prophylactics
the good of prophylactics
----------------------------------------------------------------------
Editors Corner.
This issue marks the first issue in which material from the non-sensitive
Unix security list is being gatewayed in. (Such material is easy to indentify
as it goes through the site 'zardoz' and has a longer 'From' path than most.)
With the exception of Bob Page's report on the worm, which was posted to the
phage list some time ago, I will only be forwarding phage material that is new
(and relevant).
Also, I'll adopt the convention that if I add editorial comments in the middle
of text I'll enclose them inside [] and end with --ab. Any others should
be considered present in the original.
Newcomers to the list since last issue:
Michael Erlinger (lll-winken!jarthur.claremont.edu!root)
Alan Matsuoka (rutgers!rutgers!uunet!mnetor!lsuc!dvlmarv!alanm)
Peter Jensen (rutgers!jarsun1.ZONE1.COM!jensen)
Dr Lionel M. Ni (gatech!cpswh.cps.msu.edu!ni)
Larry Pajakowski (lll-winken!ddsw1!tapa!root)
Harvard Townsend (gatech!ksuvax1.cis.ksu.edu!harv)
----------------------------------------------------------------------
Date: Thu, 1 Dec 88 22:52:50 PST
From: neil@zardoz.uucp (Neil Gorsuch)
Subject: uucico & uuclean permissions
I just noticed that the default permissions on sun workstations
for the uucp programs uucico and uuclean are as follows:
zardoz# cd /usr/lib/uucp
/usr/lib/uucp
zardoz# ls -lg uuclean uucico
---s--x--x 1 uucp staff 98304 Jul 6 17:00 uucico*
---s--x--x 1 uucp staff 49152 Nov 10 1987 uuclean*
zardoz#
"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. uuclean can be used to wipe out
pending uucp transfers.
The permissions on this system have been changed to:
zardoz# ls -lg uuclean uucico
---s--x--- 1 uucp staff 98304 Jul 6 17:00 uucico*
---s--x--- 1 uucp staff 49152 Nov 10 1987 uuclean*
zardoz#
There are probably a lot of other file permissions that are set up
badly from the vendor in the uucp system, but I have already changed
most of those and can't remember the changes.
neil@cpd.com
----------------------------------------------------------------------
Date: Mon, 21 Nov 88 19:47:10 EST
From: zardoz!ccicpg!cci632!rochester!ll-xn!ucsd!sys1.tandy.com!devon!paul (Paul Sutcliffe Jr.)
Subject: Re: (relatively) secure unshar?
John Kimball wrote:
+---------
| Someone here at SRC claims that they've seen a 'secure unshar' before,
| which un-archives a shell archive but doesn't open you up to executing
| whatever arbitrary commands are embedded in the shar. Before I consider
| re-inventing the wheel, has anyone seen such a beast?
+---------
This is what you probably heard about, enjoy!
- paul
--
Paul Sutcliffe, Jr. +---------------------------------+
| Light Year, n.: A regular year |
UUCP: paul@devon.UUCP | that has 1/3 less calories. |
or : ...rutgers!bpa!vu-vlsi!devon!paul +---------------------------------+
Shell archive follows:
----- 8< ---------- 8< ---------- 8< ---------- 8< ---------- 8< -----
#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create the files:
# unshar.c
# This archive created: Mon Nov 21 19:45:02 1988
export PATH; PATH=/bin:$PATH
echo shar: extracting "'unshar.c'" '(13477 characters)'
if test -f 'unshar.c'
then
echo shar: will not over-write existing file "'unshar.c'"
else
sed 's/^X//' << \SHAR_EOF > 'unshar.c'
X/****************************************************************
X * unshar.c: Unpackage one or more shell archive files
X *
X * Usage: unshar [-c] [-o] [ -d directory ] [ file ] ...
X *
X * Description: unshar is a filter which removes the front part
X * of a file and passes the rest to the 'sh' command.
X * knows about shell comment characters and the Unix
X * commands "echo", "cat", and "sed".
X * The -o flag causes it to preserve the header.
X * With -O also the mail headers are preserved.
X *
X * HISTORY
X * 9-Feb-85 Andries Brouwer (aeb@mcvax) at CWI, Amsterdam
X * Fixed filter mode; added -o and -O options; improved heuristics.
X * 6-Feb-85 Stephen C. Woods (scw@cepu) Los Angeles CA
X * fixed '#' for v7 flavor systems (sh dosen't know about # comments)
X * added -c flag to allow echo of skipped #comments
X * 1-Feb-85 Guido van Rossum (guido@mcvax) at CWI, Amsterdam
X * Added missing 'quit' routine;
X * added -d flag to change to directory first;
X * added filter mode (read stdin when no arguments);
X * added 'getopt' to get flags (makes it self-contained).
X * 29-Jan-85 Michael Mauldin (mlm) at Carnegie-Mellon University
X * Created.
X ****************************************************************/
X
X# include <stdio.h>
X# define EOL '\n'
X# define V7
X
Xextern char *rindex (); /* for SYSV: change to strrchr() */
Xextern char *optarg;
Xextern int optind;
Xextern char *position ();
X
Xint outheader = 0;
Xint outall = 0;
X#ifdef V7
Xint cflag = 0;
X#endif V7
X
Xmain (argc, argv)
Xint argc;
Xchar *argv[];
X{
X register int i,
X ch;
X FILE * in;
X
X /* Process options */
X
X while ((ch = getopt (argc, argv, "cd:oO")) != EOF) {
X switch (ch) {
X case 'd':
X if (chdir (optarg) == -1) {
X fprintf (stderr, "unshar: cannot chdir to '%s'\n", optarg);
X exit (2);
X }
X break;
X case 'O':
X outall++;
X /* fall into next case */
X case 'o':
X outheader++;
X break;
X#ifdef V7
X case 'c':
X cflag++;
X if (cflag == 1)
X break;
X /* fall into next case */
X default:
X quit (2, "Usage: unshar [-c] [-o or -O] [-d directory] [input files]\n");
X#else V7
X default:
X quit (2, "Usage: unshar [-o or -O] [-d directory] [input files]\n");
X#endif V7
X }
X }
X
X if (optind < argc) {
X for (i = optind; i < argc; ++i) {
X if ((in = fopen (argv[i], "r")) == NULL) {
X fprintf (stderr, "unshar: file '%s' not found\n", argv[i]);
X exit (1);
X }
X process (argv[i], in);
X fclose (in);
X }
X }
X else
X process ((char *) 0, stdin);
X
X exit (0);
X}
X
X
Xprocess (name, in)
Xchar *name;
XFILE * in;
X{
X char ch;
X register char *firstline;
X FILE * shpr, *popen ();
X
X if ((firstline = position (name, in)) != NULL) {
X printf ("%s:\n", name ? name : "standard input");
X#ifdef V7
X {
X int inline,
X comment;
X
X ch = fgetc (in);
X
X if ((inline = comment = (ch == '#'))) {
X fprintf (stderr, " skipping comments\n");
X if (cflag)
X fputc (ch, stderr);
X do {
X ch = fgetc (in);
X if (ch == EOF) {
X fprintf (stderr, "file was all comments, nothing extracted\n");
X return;
X }
X if (inline) {
X inline = ch != '\n';
X }
X else {
X inline = comment = (ch == '#');
X }
X if (comment && cflag)
X fputc (ch, stderr);
X } while (comment);
X }
X ungetc (ch, in);
X }
X#endif V7
X if ((shpr = popen ("sh", "w")) == NULL)
X quit (1, "unshar: cannot open 'sh' process\n");
X fputs (firstline, shpr);
X while ((ch = fgetc (in)) != EOF)
X fputc (ch, shpr);
X
X pclose (shpr);
X }
X}
X
X/****************************************************************
X * position: position 'fil' at the start of the shell command
X * portion of a shell archive file.
X ****************************************************************/
X
Xchar *
X position (fn, fil)
Xchar *fn;
XFILE * fil;
X{
X char buf[BUFSIZ],
X bufl[BUFSIZ];
X FILE * hdr;
X register char *xfn = fn ? fn : "the standard input";
X short inmailheader;
X
X if (outheader) {
X char hdrnam[15];
X if (fn) {
X register char *base = strrchr (fn, '/');
X
X strncpy (hdrnam, base ? base + 1 : fn, 14);
X hdrnam[10] = 0;
X strcat (hdrnam, ".hdr");
X }
X else {
X printf ("Sending header to unshar.hdr\n");
X strcpy (hdrnam, "unshar.hdr");
X }
X if ((hdr = fopen (hdrnam, "a")) == NULL) {
X fprintf (stderr, "unshar: cannot open %s\n", hdrnam);
X return (0);
X }
X inmailheader = 1;
X }
X
X while (1) {
X /* Read next line, fail if no more */
X if (fgets (buf, BUFSIZ, fil) == NULL) {
X fprintf (stderr, "unshar: found no shell commands in %s\n", xfn);
X return (0);
X }
X
X /* Bail out if we see C preprocessor commands or C comments */
X if (looks_C (buf)) {
X fprintf (stderr,
X "unshar: %s looks like raw C code, not a shell archive\n",
X xfn);
X return (0);
X }
X
X if (looks_PASCAL (buf)) {
X fprintf (stderr,
X "unshar: %s looks like raw PASCAL code, not a shell archive\n",
X xfn);
X return (0);
X }
X
X if (looks_TROFF (buf)) {
X fprintf (stderr,
X "unshar: %s looks like raw TROFF input, not a shell archive\n",
X xfn);
X return (0);
X }
X
X /* Does this line start with a shell command or comment */
X if ((stlmatch (buf, "#") && !textline (buf)) || stlmatch (buf, ":") ||
X stlmatch (buf, "echo ") || stlmatch (buf, "sed ") ||
X stlmatch (buf, "cat ")) {
X if (outheader)
X (void) fclose (hdr);
X return (buf);
X }
X
X /* Does this line say "Cut here" */
X /* Of course we have to be a little careful: for example it says in a
X recent distribution: ... this program is cute, but there are ... */
X tolowercase (buf, bufl);
X if (stlmatch (buf, "--------") ||
X contains (bufl, "cut", "here") ||
X contains (bufl, "cut", "cut") ||
X contains (bufl, "tear", "here")) {
X while (1) {
X if (fgets (buf, BUFSIZ, fil) == NULL) {
X fprintf (stderr,
X "unshar: found no shell commands after 'cut' in %s\n",
X fn ? fn : "the standard input");
X return (0);
X }
X
X if (*buf != '\n')
X break;
X }
X
X /* Win if line starts with a comment character of lower case
X letter */
X if (*buf == '#' || *buf == ':' || (('a' <= *buf) && ('z' >= *buf)))
X return (buf);
X
X /* Cut here message lied to us */
X fprintf (stderr, "unshar: %s is probably not a shell archive,\n", fn);
X fprintf (stderr, " the 'cut' line was followed by: %s", buf);
X return (0);
X }
X
X if (outheader) {
X if (inmailheader && !mailheaderline (buf))
X inmailheader = 0;
X if (!inmailheader || outall)
X fputs (buf, hdr);
X }
X }
X}
X
X/*****************************************************************
X * stlmatch -- match leftmost part of string
X *
X * Usage: i = stlmatch (big,small)
X * int i;
X * char *small, *big;
X *
X * Returns 1 iff initial characters of big match small exactly;
X * else 0.
X *
X * HISTORY
X * 18-May-82 Michael Mauldin (mlm) at Carnegie-Mellon University
X * Ripped out of CMU lib for Rog-O-Matic portability
X * 20-Nov-79 Steven Shafer (sas) at Carnegie-Mellon University
X * Rewritten for VAX from Ken Greer's routine.
X *
X * Originally from klg (Ken Greer) on IUS/SUS UNIX
X *****************************************************************/
X
Xint stlmatch (big, small)
Xchar *small,
X *big;
X{
X register char *s,
X *b;
X s = small;
X b = big;
X do {
X if (*s == '\0')
X return (1);
X }
X while (*s++ == *b++);
X return (0);
X}
X
X/*****************************************************************
X * smatch: Given a data string and a pattern containing one or
X * more embedded stars (*) (which match any number of characters)
X * return true if the match succeeds, and set res[i] to the
X * characters matched by the 'i'th *.
X *****************************************************************/
X
Xsmatch (dat, pat, res)
Xregister char *dat,
X *pat,
X **res;
X{
X register char *star = 0,
X *starend,
X *resp;
X int nres = 0;
X
X while (1) {
X if (*pat == '*') {
X star = ++pat; /* Pattern after * */
X starend = dat; /* Data after * match */
X resp = res[nres++]; /* Result string */
X *resp = '\0'; /* Initially null */
X }
X else
X if (*dat == *pat) { /* Characters match */
X if (*pat == '\0')/* Pattern matches */
X return (1);
X pat++; /* Try next position */
X dat++;
X }
X else {
X if (*dat == '\0')/* Pattern fails - no more */
X return (0); /* data */
X if (star == 0) /* Pattern fails - no * to */
X return (0); /* adjust */
X pat = star; /* Restart pattern after * */
X *resp++ = *starend;/* Copy character to result */
X *resp = '\0'; /* null terminate */
X dat = ++starend;/* Rescan after copied char */
X }
X }
X}
X
X/*****************************************************************
X * Addendum: quit subroutine (print a message and exit)
X *****************************************************************/
X
Xquit (status, message)
Xint status;
Xchar *message;
X{
X fprintf (stderr, message);
X exit (status);
X}
X
X/*****************************************************************
X * Public Domain getopt routine
X *****************************************************************/
X
X/*
X * get option letter from argument vector
X */
Xint optind = 1, /* strchr into parent argv vector */
X optopt; /* character checked for validity */
Xchar *optarg; /* argument associated with option */
X
X#define BADCH (int)'?'
X#define EMSG ""
X#define tell(s) fputs(*nargv,stderr);fputs(s,stderr); \
Xfputc (optopt, stderr); \
Xfputc ('\n', stderr); \
Xreturn (BADCH);
X
Xgetopt (nargc, nargv, ostr)
Xint nargc;
Xchar **nargv,
X *ostr;
X{
X static char *place = EMSG; /* option letter processing */
X register char *oli; /* option letter list strchr */
X char *strchr ();
X
X if (!*place) { /* update scanning pointer */
X if (optind >= nargc || *(place = nargv[optind]) != '-' || !*++place)
X return (EOF);
X if (*place == '-') { /* found "--" */
X ++optind;
X return (EOF);
X }
X } /* option letter okay? */
X if ((optopt = (int) * place++) == (int) ':' ||
X !(oli = strchr (ostr, optopt))) {
X if (!*place)
X ++optind;
X tell (": illegal option -- ");
X }
X if (*++oli != ':') { /* don't need argument */
X optarg = NULL;
X if (!*place)
X ++optind;
X }
X else { /* need an argument */
X if (*place)
X optarg = place; /* no white space */
X else
X if (nargc <= ++optind) {/* no arg */
X place = EMSG;
X tell (": option requires an argument -- ");
X }
X else
X optarg = nargv[optind];/* white space */
X place = EMSG;
X ++optind;
X }
X return (optopt); /* dump back option letter */
X}
X
X/********************************************************************
X *
X * Differentiate mail headers from the rest of the article.
X *
X ********************************************************************/
X
Xmailheaderline (buf)
Xregister char *buf;
X{
X register int cnt = 0;
X
X if (!*buf || *buf == '\n')
X return (0);
X if (*buf == ' ' || *buf == '\t')
X return (1);
X while (letdig (*buf)) {
X buf++;
X cnt++;
X }
X return (cnt && *buf == ':');
X}
X
Xletdig (c) /* Symbols found in field tags, like
X Article-I.D.: */
Xchar c;
X{
X return (c == '-' || c == '_' || c == '.' || digit (c) || letter (c));
X}
X
X/*
X * Some shar's produce output like:
X * # This is a shell archive.
X * # ...
X * #!/bin/sh
X *
X * so if we haven't seen the 'cut' message yet, we have to skip #text lines.
X */
Xtextline (buf)
Xregister char *buf;
X{
X if (*buf == '#')
X buf++;
X while (textsym (*buf))
X buf++;
X return (!*buf);
X}
X
Xtextsym (c)
Xchar c;
X{
X return (letter (c) ||
X c == ' ' || c == '\t' || c == '\n' || c == ',' || c == '.');
X}
X
X/****************************************************************
X *
X * Recognize various types of files.
X *
X ****************************************************************/
X
Xlooks_C (buf)
Xregister char *buf;
X{
X return (stlmatch (buf, "#include") || stlmatch (buf, "# include") ||
X stlmatch (buf, "#define") || stlmatch (buf, "# define") ||
X stlmatch (buf, "#ifdef") || stlmatch (buf, "# ifdef") ||
X stlmatch (buf, "#ifndef") || stlmatch (buf, "# ifndef") ||
X stlmatch (buf, "/*")
X );
X}
X
Xlooks_PASCAL (buf)
Xregister char *buf;
X{
X return (stlmatch (buf, "(*"));
X}
X
Xlooks_TROFF (buf)
Xregister char *buf;
X{
X return (*buf == '.' &&
X letter (buf[1]) && letter (buf[2]) && !letter (buf[3]));
X}
X
X/************************************************************
X *
X * Some miscellaneous goodies
X *
X ************************************************************/
X
Xletter (c)
Xchar c;
X{
X return (('a' <= c && c <= 'z') || ('A' <= c && c <= 'Z'));
X}
X
Xdigit (c)
Xchar c;
X{
X return ('0' <= c && c <= '9');
X}
X
Xtolowercase (buf, bufl)
Xregister char *buf,
X *bufl;
X{
X while (*buf) {
X if ('A' <= *buf && *buf <= 'Z')
X *bufl++ = *buf++ + ('a' - 'A');
X else
X *bufl++ = *buf++;
X }
X *bufl = 0;
X}
X
X/* check whether buf contains wd1 and wd2 as words
X (i.e., no preceding or following letters) */
Xcontains (buf, wd1, wd2)
Xregister char *buf, *wd1, *wd2;
X{
X register char *wd = wd1;
X int first = 1;
X
Xagain:
X while (*buf) {
X if (!letter (*buf)) {
X buf++;
X continue;
X }
X while (*buf++ == *wd++) {
X if (!*wd) {
X if (!letter (*buf)) {
X if (!first)
X return (1);
X first = 0;
X wd = wd2;
X goto again;
X }
X break;
X }
X }
X while (letter (*buf))
X buf++;
X wd = first ? wd1 : wd2;
X }
X return (0);
X}
SHAR_EOF
if test 13477 -ne "`wc -c < 'unshar.c'`"
then
echo shar: error transmitting "'unshar.c'" '(should have been 13477 characters)'
fi
fi # end of overwriting check
# End of shell archive
exit 0
----------------------------------------------------------------------
Date: Tue, 22 Nov 88 00:37:40 EST
From: zardoz!ccicpg!cci632!rochester!ll-xn!ucsd!uunet.UU.NET!attcan!utzoo!henry
Subject: Re: uucp security hole and fix
> The practice of using ~uucp to refer to /usr/spool/uucppublic is a Berkeley-
> ism, both unnecessary and dangerous...
Ah, the ignorance of youth... :-) ~uucp is not a Berkeleyism, it's a
Usenetism, dating from the very early days of the net. And although it
is unnecessary today, it wasn't always so: very early uucps, like the
V7 one, did not understand ~/ to mean uucppublic.
Henry Spencer at U of Toronto Zoology
uunet!attcan!utzoo!henry henry@zoo.toronto.edu
----------------------------------------------------------------------
Date: Tue, 22 Nov 88 21:03:31 PST
From: neil@zardoz.uucp (Neil Gorsuch)
Subject: Re: [Dennis G. Rears (FSAC): [Ken van Wyk: (long) report on the Internet Worm]]
In case anyone missed this in the news group comp.unix.wizards:
In article <17516@adm.BRL.MIL>:
F Y I
----- Forwarded message # 1:
Received: from [192.12.8.16] by ARDEC-CC1.ARDEC.ARPA id aa15458;
14 Nov 88 9:28 EST
Date: Mon, 14 Nov 88 9:27:57 EST
From: "Dennis G. Rears (FSAC)" <drears@ARDEC.ARPA>
To: mchinni@ARDEC.ARPA
Subject: [Ken van Wyk: (long) report on the Internet Worm]
Message-ID: <8811140927.aa28068@ARDEC-AC4.ARDEC.ARPA>
FYI, this came from RISKS.
...dgr
----- Forwarded message # 1:
Date: Fri, 11 Nov 88 13:57:42 EST
Sender: Virus Discussion List <VIRUS-L@IBM1.CC.Lehigh.Edu>
From: Ken van Wyk <luken@SPOT.CC.LEHIGH.EDU>
Subject: (long) report on the Internet Worm
A REPORT ON THE INTERNET WORM
Bob Page
University of Lowell
Computer Science Department
November 7, 1988
[Because of the many misquotes the media have been giving,
this report is Copyright (c) Bob Page, all rights reserved.
Permission is granted to republish this ONLY if you republish
it in its entirety.]
Here's the scoop on the "Internet Worm". Actually it's not a virus -
a virus is a piece of code that adds itself to other programs,
including operating systems. It cannot run independently, but rather
requires that its "host" program be run to activate it. As such, it
has a clear analog to biologic viruses -- those viruses are not
considered live, but they invade host cells and take them over, making
them produce new viruses.
A worm is a program that can run by itself and can propagate a fully
working version of itself to other machines. As such, what was loosed
on the Internet was clearly a worm.
This data was collected through an emergency mailing list set up by
Gene Spafford at Purdue University, for administrators of major
Internet sites - some of the text is included verbatim from that list.
Mail was heavy since the formation of the list; it continues to be on
Monday afternoon - I get at least 2-3 messages every hour. It's
possible that some of this information is incomplete, but I thought
you'd like to know what I know so far.
The basic object of the worm is to get a shell on another machine so
it can reproduce further. There are three ways it attacks: sendmail,
fingerd, and rsh/rexec.
THE SENDMAIL ATTACK:
In the sendmail attack, the worm opens a TCP connection to another
machine's sendmail (the SMTP port), invokes debug mode, and sends a
RCPT TO that requests its data be piped through a shell. That data, a
shell script (first-stage bootstrap) creates a temporary second-stage
bootstrap file called x$$,l1.c (where '$$' is the current process ID).
This is a small (40-line) C program.
The first-stage bootstrap compiles this program with the local cc and
executes it with arguments giving the Internet hostid/socket/password
of where it just came from. The second-stage bootstrap (the compiled
C program) sucks over two object files, x$$,vax.o and x$$,sun3.o from
the attacking host. It has an array for 20 file names (presumably for
20 different machines), but only two (vax and sun) were compiled in to
this code. It then figures out whether it's running under BSD or
SunOS and links the appropriate file against the C library to produce
an executable program called /usr/tmp/sh - so it looks like the Bourne
shell to anyone who looked there.
THE FINGERD ATTACK:
In the fingerd attack, it tries to infiltrate systems via a bug in
fingerd, the finger daemon. Apparently this is where most of its
success was (not in sendmail, as was originally reported). When
fingerd is connected to, it reads its arguments from a pipe, but
doesn't limit how much it reads. If it reads more than the internal
512-byte buffer allowed, it writes past the end of its stack. After
the stack is a command to be executed ("/usr/ucb/finger") that
actually does the work. On a VAX, the worm knew how much further from
the stack it had to clobber to get to this command, which it replaced
with the command "/bin/sh" (the bourne shell). So instead of the
finger command being executed, a shell was started with no arguments.
Since this is run in the context of the finger daemon, stdin and
stdout are connected to the network socket, and all the files were
sucked over just like the shell that sendmail provided.
THE RSH/REXEC ATTACK:
The third way it tried to get into systems was via the .rhosts and
/etc/hosts.equiv files to determine 'trusted' hosts where it might be
able to migrate to. To use the .rhosts feature, it needed to actually
get into people's accounts - since the worm was not running as root
(it was running as daemon) it had to figure out people's passwords.
To do this, it went through the /etc/passwd file, trying to guess
passwords. It tried combinations of: the username, the last, first,
last+first, nick names (from the GECOS field), and a list of special
"popular" passwords:
aaa cornelius guntis noxious simon
academia couscous hacker nutrition simple
aerobics creation hamlet nyquist singer
airplane creosote handily oceanography single
albany cretin happening ocelot smile
albatross daemon harmony olivetti smiles
albert dancer harold olivia smooch
alex daniel harvey oracle smother
alexander danny hebrides orca snatch
algebra dave heinlein orwell snoopy
aliases december hello osiris soap
alphabet defoe help outlaw socrates
ama deluge herbert oxford sossina
amorphous desperate hiawatha pacific sparrows
analog develop hibernia painless spit
anchor dieter honey pakistan spring
andromache digital horse pam springer
animals discovery horus papers squires
answer disney hutchins password strangle
anthropogenic dog imbroglio patricia stratford
anvils drought imperial penguin stuttgart
anything duncan include peoria subway
aria eager ingres percolate success
ariadne easier inna persimmon summer
arrow edges innocuous persona super
arthur edinburgh irishman pete superstage
athena edwin isis peter support
atmosphere edwina japan philip supported
aztecs egghead jessica phoenix surfer
azure eiderdown jester pierre suzanne
bacchus eileen jixian pizza swearer
bailey einstein johnny plover symmetry
banana elephant joseph plymouth tangerine
bananas elizabeth joshua polynomial tape
bandit ellen judith pondering target
banks emerald juggle pork tarragon
barber engine julia poster taylor
baritone engineer kathleen praise telephone
bass enterprise kermit precious temptation
bassoon enzyme kernel prelude thailand
batman ersatz kirkland prince tiger
beater establish knight princeton toggle
beauty estate ladle protect tomato
beethoven euclid lambda protozoa topography
beloved evelyn lamination pumpkin tortoise
benz extension larkin puneet toyota
beowulf fairway larry puppet trails
berkeley felicia lazarus rabbit trivial
berliner fender lebesgue rachmaninoff trombone
beryl fermat lee rainbow tubas
beverly fidelity leland raindrop tuttle
bicameral finite leroy raleigh umesh
bob fishers lewis random unhappy
brenda flakes light rascal unicorn
brian float lisa really unknown
bridget flower louis rebecca urchin
broadway flowers lynne remote utility
bumbling foolproof macintosh rick vasant
burgess football mack ripple vertigo
campanile foresight maggot robotics vicky
cantor format magic rochester village
cardinal forsythe malcolm rolex virginia
carmen fourier mark romano warren
carolina fred markus ronald water
caroline friend marty rosebud weenie
cascades frighten marvin rosemary whatnot
castle fun master roses whiting
cat fungible maurice ruben whitney
cayuga gabriel mellon rules will
celtics gardner merlin ruth william
cerulean garfield mets sal williamsburg
change gauss michael saxon willie
charles george michelle scamper winston
charming gertrude mike scheme wisconsin
charon ginger minimum scott wizard
chester glacier minsky scotty wombat
cigar gnu moguls secret woodwind
classic golfer moose sensor wormwood
clusters gorgeous morley serenity yaco
coffee gorges mozart sharks yang
coke gosling nancy sharon yellowstone
collins gouge napoleon sheffield yosemite
commrades graham nepenthe sheldon zap
computer gryphon ness shiva zimmerman
condo guest network shivers
cookie guitar newton shuttle
cooper gumption next signature
[I wouldn't have picked some of these as "popular" passwords, but
then again, I'm not a worm writer. What do I know?]
When everything else fails, it opens /usr/dict/words and tries every
word in the dictionary. It is pretty successful in finding passwords,
as most people don't choose them very well. Once it gets into
someone's account, it looks for a .rhosts file and does an 'rsh'
and/or 'rexec' to another host, it sucks over the necessary files into
/usr/tmp and runs /usr/tmp/sh to start all over again.
Between these three methods of attack (sendmail, fingerd, .rhosts)
it was able to spread very quickly.
THE WORM ITSELF:
The 'sh' program is the actual worm. When it starts up it clobbers
its argv array so a 'ps' will not show its name. It opens all its
necessary files, then unlinks (deletes) them so they can't be found
(since it has them open, however, it can still access the contents).
It then tries to infect as many other hosts as possible - when it
sucessfully connects to one host, it forks a child to continue the
infection while the parent keeps on trying new hosts.
One of the things it does before it attacks a host is connect to the
telnet port and immediately close it. Thus, "telnetd: ttloop: peer
died" in /usr/adm/messages means the worm attempted an attack.
The worm's role in life is to reproduce - nothing more. To do that it
needs to find other hosts. It does a 'netstat -r -n' to find local
routes to other hosts & networks, looks in /etc/hosts, and uses the
yellow pages distributed hosts file if it's available. Any time it
finds a host, it tries to infect it through one of the three methods,
see above. Once it finds a local network (like 129.63.nn.nn for
ulowell) it sequentially tries every address in that range.
If the system crashes or is rebooted, most system boot procedures
clear /tmp and /usr/tmp as a matter of course, erasing any evidence.
However, sendmail log files show mail coming in from user /dev/null
for user /bin/sed, which is a tipoff that the worm entered.
Each time the worm is started, there is a 1/15 chance (it calls
random()) that it sends a single byte to ernie.berkeley.edu on some
magic port, apparently to act as some kind of monitoring mechanism.
THE CRACKDOWN:
Three main 'swat' teams from Berkeley, MIT and Purdue found copies of
the VAX code (the .o files had all the symbols intact with somewhat
meaningful names) and disassembled it into about 3000 lines of C. The
BSD development team poked fun at the code, even going so far to point
out bugs in the code and supplying source patches for it! They have
not released the actual source code, however, and refuse to do so.
That could change - there are a number of people who want to see the
code.
Portions of the code appear incomplete, as if the program development
was not yet finished. For example, it knows the offset needed to
break the BSD fingerd, but doesn't know the correct offset for Sun's
fingerd (which causes it to dump core); it also doesn't erase its
tracks as cleverly as it might; and so on.
The worm uses a variable called 'pleasequit' but doesn't correctly
initialize it, so some folks added a module called _worm.o to the C
library, which is produced from:
int pleasequit = -1;
the fact that this value is set to -1 will cause it to exit after one
iteration.
The close scrutiny of the code also turned up comments on the
programmer's style. Verbatim from someone at MIT:
From disassembling the code, it looks like the programmer
is really anally retentive about checking return codes,
and, in addition, prefers to use array indexing instead of
pointers to walk through arrays.
Anyone who looks at the binary will not see any embedded strings -
they are XOR'ed with 81 (hex). That's how the shell commands are
imbedded. The "obvious" passwords are stored with their high bit set.
Although it spreads very fast, it is somewhat slowed down by the fact
that it drives the load average up on the machine - this is due to all
the encryptions going on, and the large number of incoming worms from
other machines.
[Initially, the fastest defense against the worm is is to create a
directory called /usr/tmp/sh. The script that creates /usr/tmp/sh
from one of the .o files checks to see if /usr/tmp/sh exists, but not
to see if it's a directory. This fix is known as 'the condom'.]
NOW WHAT?
None of the ULowell machines were hit by the worm. When BBN staffers
found their systems infected, they cut themselves off from all other
hosts. Since our connection to the Internet is through BBN, we were
cut off as well. Before we were cut off, I received mail about the
sendmail problem and installed a patch to disable the feature the worm
uses to get in through sendmail. I had made local modifications to
fingerd which changed the offsets, so any attempt to scribble over the
stack would probably have ended up in a core dump.
Most Internet systems running 4.3BSD or SunOS have installed the
necessary patches to close the holes and have rejoined the Internet.
As you would expect, there is a renewed interest in system/network
security, finding and plugging holes, and speculation over what
will happen to the worm's creator.
If you haven't read or watched the news, various log files have named
the responsible person as Robert Morris Jr., a 23-year old doctoral
student at Cornell. His father is head of the National Computer
Security Center, the NSA's public effort in computer security, and has
lectured widely on security aspects of UNIX.
Associates of the student claim the worm was a 'mistake' - that he
intended to unleash it but it was not supposed to move so quickly or
spread so much. His goal (from what I understand) was to have a
program 'live' within the Internet. If the reports that he intended
it to spread slowly are true, then it's possible that the bytes sent
to ernie.berkeley.edu were intended to monitor the spread of the
worm. Some news reports mentioned that he panicked when, via some
"monitoring mechanism" he saw how fast it had propagated.
A source inside DEC reports that although the worm didn't make much
progress there, it was sighted on several machines that wouldn't be
on its normal propagation path, i.e. not gateways and not on the same
subnet. These machines are not reachable from the outside. Morris
was a summer intern at DEC in '87. He might have included names or
addresses he remembered as targets for infesting hidden internal
networks. Most of the DEC machines in question belong to the group he
worked in.
The final word has not been written - I don't think the FBI have even
met with this guy yet. It will be interesting to see what happens.
----------------------------------------------------------------------
Date: Sun, 20 Nov 88 02:03:34 EST
From: der Mouse <mouse@larry.mcrcim.mcgill.edu>
Subject: .forward vs aliases
> .forward should always override
> (/usr/lib/upas/namefiles|/usr/lib/aliases) for real people
> (non-system accounts).
I disagree. It is not the mailer's business to try to second-guess the
mail admin. For that matter, it's not the mailer's business to know
who's a real person and who isn't.
> what a person does with their own mail is their own business.
Usually but not always. Remember, the owners of the machine get first
say, though they usually choose not to exercise this prerogative. But
that's all beside the point unless you want to hypothesize a mechanism
by which the mailer can know what codes correspond to persons and what
codes don't.
Bottom line is: don't try to make the software second-guess the admin.
If the admin chooses to provide a system alias for a real user, who are
we to say we know better and refuse to listen to it?
der Mouse
old: mcgill-vision!mouse
new: mouse@larry.mcrcim.mcgill.edu
----------------------------------------------------------------------
Date: Sat, 19 Nov 88 15:06:35 PST
From: steve@polyslo.calpoly.edu (Steve DeJarnett)
Subject: Re: DANGER: UUCP *can* propogate the Worm
> Date: Fri, 18 Nov 88 12:06:16 PST
> From: ames!pyramid.pyramid.com!csg@EA.ECN.PURDUE.EDU (Carl S. Gutekunst)
> Reply-To: ames!pyramid.pyramid.com!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.
On Pyramid's, /usr/spool/at as shipped is owned by root (not daemon).
I think that's why Carl wasn't as worried about that (at least on his systems).
> 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.
Too true.
-------------------------------------------------------------------------------
| Steve DeJarnett | Smart Mailers -> steve@polyslo.CalPoly.EDU |
| Computer Systems Lab | Dumb Mailers -> ..!ucbvax!voder!polyslo!steve |
| Cal Poly State Univ. |------------------------------------------------|
| San Luis Obispo, CA 93407 | BITNET = Because Idiots Type NETwork |
-------------------------------------------------------------------------------
----------------------------------------------------------------------
Date: Fri, 18 Nov 88 12:06:16 PST
From: ames!pyramid.pyramid.com!csg@ea.ecn.purdue.edu (Carl S. Gutekunst)
Subject: Re: DANGER: UUCP *can* propogate the Worm
This is long, but Mel alludes to at least one more serious sendmail security
hole. So bear with me. There's a sendmail patch at the very end.
Mel Pleasant writes:
>Someone else pointed out a related problem with sendmail where
>a local user can take advantage of the sendmail hole. You probably
>want to remove all references to tTd(0, 1) in the sendmail sources.
(In other words, delete all tests for Debug Flag 0 being enabled. Sendmail has
100 debugging flags; the -d option or the SMTP debug command sets them all to
1. You can puts arguments on the -d option to only enable certain flags.)
Or just restrict the "dangerous" debug functions to root. I think this may be
just as safe and certainly more friendly than completely restricting debugging
to root, as I suggested in my original article. And it will allow SysAdmins to
continue to use the old features.
Note that Flag 0 also controls some benign things: printing the host's canon-
ical name and all aliases, printing an interpretted list of mailers from the
configuration file, and printing the addresses of the argument vector table.
It also determines whether or not daemon mode (-bd) will put sendmail into the
background; I'm not sure how dangerous this is.
How's *that* for overloading of operators? :-(
>Its [tTd(0, 1)] occurrences allow sendmail to run programs, append directly
>to files (as recipients), or cause sendmail to include a list of names as
>a mailing list (:include:).
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.
Mailing to files is less of a problem; the file has to be (practically) world
writable. But I agree, there's no reason for normal users to have this capa-
bility. So it goes out, too.
The :include: mechanism seems harmless enough, and it *is* useful to users who
are maintaining mailing lists. (They can test out the list before giving it to
a system administrator to install.) Unfortunately, sendmail opens the include
file with root permissions, and displays it! (Yet another way to read any file
on the machine, folks.) Rather then remove this useful debugging facility, I
chose to fix it: I have the include() function check the file with access(2)
before opening it. This also introduces a new security feature: if a :include:
file has 600 permissions, then only the owner or root can mail through it.
My new patch for sendmail 5.59 follows, with the following changes:
- Mail to pipes and files is restricted to /usr/lib/aliases, .forward files,
and root debugging;
- Check permissions before opening an :include: file.
You more paranoid types can remove the calls to !tTd(0, 1) instead.
<csg>
_______________________________________________________________________________
*** recipient.c.old Sun Mar 13 21:31:54 1988
--- recipient.c Mon Nov 14 12:19:52 1988
***************
*** 20,25
# include <pwd.h>
# include "sendmail.h"
# include <sys/stat.h>
/*
--- 20,26 -----
# include <pwd.h>
# include "sendmail.h"
+ # include <sys/file.h>
# include <sys/stat.h>
/*
***************
*** 202,208
{
a->q_mailer = m = ProgMailer;
a->q_user++;
! if (a->q_alias == NULL && !tTd(0, 1) && !QueueRun && !ForceMail)
{
a->q_flags |= QDONTSEND|QBADADDR;
usrerr("Cannot mail directly to programs");
--- 203,210 -----
{
a->q_mailer = m = ProgMailer;
a->q_user++;
! if (a->q_alias == NULL && !(tTd(0, 1) && getruid() == 0)
! && !QueueRun && !ForceMail)
{
a->q_flags |= QDONTSEND|QBADADDR;
usrerr("Cannot mail directly to programs");
***************
*** 284,290
{
p = rindex(buf, '/');
/* check if writable or creatable */
! if (a->q_alias == NULL && !tTd(0, 1) && !QueueRun && !ForceMail)
{
a->q_flags |= QDONTSEND|QBADADDR;
usrerr("Cannot mail directly to files");
--- 286,293 -----
{
p = rindex(buf, '/');
/* check if writable or creatable */
! if (a->q_alias == NULL && !(tTd(0, 1) && getruid() == 0)
! && !QueueRun && !ForceMail)
{
a->q_flags |= QDONTSEND|QBADADDR;
usrerr("Cannot mail directly to files");
***************
*** 475,480
char *oldfilename = FileName;
int oldlinenumber = LineNumber;
fp = fopen(fname, "r");
if (fp == NULL)
{
--- 478,488 -----
char *oldfilename = FileName;
int oldlinenumber = LineNumber;
+ if (access(fname, R_OK))
+ {
+ usrerr("Cannot access %s", fname);
+ return;
+ }
fp = fopen(fname, "r");
if (fp == NULL)
{
----------------------------------------------------------------------
Date: Mon, 21 Nov 88 01:10:37 EST
From: rick@seismo.css.gov (Rick Adams)
Subject: Re: ~uucp/.forward
Don't forget that if you can write into ~uucp/.forward,
you can also write into ~uucp/.rhosts
----------------------------------------------------------------------
Date: Mon, 21 Nov 88 16:51:12 EST
From: rick@seismo.css.gov (Rick Adams)
Subject: Re: ~uucp/.forward
Well, it depends on what your "uucp" account is used for.
On some systems, "uucp" has a login shell, and the sites that
expect to get a uucico use "nuucp" or their sitename or something.
On uunet, "uucp" gets you /bin/sh, while your sitename gets
you uucico.
It all depends on how you set things up.
---rick
----------------------------------------------------------------------
Date: Mon, 21 Nov 88 02:20:32 EST
From: der Mouse <mouse@larry.mcrcim.mcgill.edu>
Subject: Re: ~uucp/.forward
> Don't forget that if you can write into ~uucp/.forward, you can also
> write into ~uucp/.rhosts
But that doesn't buy you much, because rlogin/rsh/rcp (the things that
use .rhosts) all use the user's shell. Rlogin will give you a uucp
connection, such as you might get by telnetting to the uucp port. Rsh
likewise, with a complaint about the -c option passed by the daemon.
Rcp doesn't work any better. (I just tried all three.) Or do .rhosts
files control something else that hasn't occured to me yet?
der Mouse
old: mcgill-vision!mouse
new: mouse@larry.mcrcim.mcgill.edu
----------------------------------------------------------------------
Date: Sun, 20 Nov 88 10:05:13 est
From: Barry Shein <encore!pinocchio!bzs@talcott.harvard.edu>
Subject: DANGER: UUCP *can* propogate the Worm
There's nothing inherently wrong in using multiple uid's (your summary
seemed complete enough) for various sub-systems. I would guess that
many people, including myself, have used that kind of thing. A lot of
the games wanted special access to their scores file thru setuid
execution so we used the pseudo-user falcon (maybe that's spelled
wrong, as in war games) to own the scores files rather than root or
whatever they recommended.
On the other hand I think we have to be cautious about fooling
ourselves. People are proposing all sorts of prophylactic security
mechanisms (this one, shadow passwds etc) which I believe is a bad
thing to stress in general. It seems to be the management of
insecurity rather than any attempt to create security. Have we really
given up and just decided to limit the damage? Sounds like a bad idea.
Also an infinite pit into which we will regret having slipped.
-Barry Shein, ||Encore||
----------------------------------------------------------------------
Date: Mon, 21 Nov 88 11:17:29 PST
From: bostic@okeeffe.berkeley.edu (Keith Bostic)
Subject: UNIX security
There are two points I would like to make regarding recent articles I've
seen on tcp-ip, phage, comp.unix.whatever and several other mailing lists.
The first concerns the widespread belief that "everybody" knew about the
bugs used by the worm. This is not true. Rick Adams has been trying to
contact "everybody" for about two weeks and he's come up emptyhanded. The
number of people that knew about fingerd seems to be less than five, with
a like number knowing about the sendmail debug problem. Counting whomever
wrote the worm. Neither Sun nor UC Berkeley knew about the bug.
My second concern is the equally widespread belief that UNIX isn't secure
and that it cannot be made secure; this belief is typified by quotes along
the lines of "I have known about the security holes in Unix for almost ten
years" and "I've got lists of UNIX security problems you wouldn't believe."
UNIX is neither more or less secure than any other general purpose operating
system I'm aware of. It can be made as secure as you wish -- Gould, Sun,
and AT&T, among others, have done interesting work in this area.
Now, the lists of security problesm, the ten-year-old bug lists, and the fact
that the tiger team from somewhere broke the su command in 1970-something,
that's ancient history. UNIX is a fairly fast moving target, and we might as
well get used to that. It's a feature, not a bug. Ten years ago we were
running Version 7 on PDP 11/34's; I trust that most of the split I/D security
issues have been addressed.
Keith Bostic
----------------------------------------------------------------------
From: bhoward@sol.engin.umich.edu
Date: 20 Nov 1988 19:12 EST
Subject: Re: .forward vs aliases
From: der Mouse <mouse@larry.mcrcim.mcgill.edu>
To: phage@purdue.edu
Date: Sun, 20 Nov 88 02:03:34 EST
Subject: .forward vs aliases
> .forward should always override
> (/usr/lib/upas/namefiles|/usr/lib/aliases) for real people
> (non-system accounts).
I disagree. It is not the mailer's business to try to second-guess the
mail admin. For that matter, it's not the mailer's business to know
who's a real person and who isn't.
> what a person does with their own mail is their own business.
Usually but not always. Remember, the owners of the machine get first
say, though they usually choose not to exercise this prerogative. But
that's all beside the point unless you want to hypothesize a mechanism
by which the mailer can know what codes correspond to persons and what
codes don't.
Bottom line is: don't try to make the software second-guess the admin.
If the admin chooses to provide a system alias for a real user, who are
we to say we know better and refuse to listen to it?
der Mouse
old: mcgill-vision!mouse
new: mouse@larry.mcrcim.mcgill.edu
its not the mailer admin's business to second guess the user. university of
michigan owns my machine, but i own my mail so i find your argument difficult
to accept. i suppose it depends on whom you consider more important; the
users or the owners or the machines. in my environment, one can argue that
the users at some level do own the machines and so must their wishes as to
where their mail ought to go.
i use a simple algorithm to discern real users from system entitites; sit down
first time i set up rewrite rules, and put in one line to reroute mail to any
accounts i know are system entitities. rewrite rules have precedence over
.forward have precedence over system aliases with my mailer so i just insert:
^(uucp|daemon|sys|bin|sysdiag|news|ingres)$ alias postmaster
in the rewrite rules and let .forward and alias files handle the rest.
this really is hair splitting because if a mail admin tried deciding what
i should do with my mail, i would find somewhere else to read my mail.
bruce
----------------------------------------------------------------------
Date: Sun, 20 Nov 88 01:10:53 PST
From: csg@pyramid.pyramid.com (Carl S. Gutekunst)
Subject: Re: ~uucp/.forward
Rich Sez:
>I believe it is time to post information on the "rmail" hole NOW.
Arrggghhh. I don't need these moral dilemmas! While I don't care for Peter's
Security Glasnost, I'm not crazy about keeping all this stuff under the table,
either. Help! Spaf, lend me your wisdom.... If you guys say do it, I will. Of
course, I'll post sources for the new rmail.c as well.
Incidentally, I've been pretty unhappy about the general badmouthing UNIX
vendors have gotten, particularly Vernon Schryver's claim that posting these
security holes is the only way to get vendors to fix them. I *can't* be the
only vendor's R&D person who is banging his head against the wall over this
stuff. I mean, there's Barry Shein, and Paul Vixie, and.... But Vernon *is* a
vendor's R&D person, so maybe he's allowed to prod the rest of us? :-)
And what Peter said that started this latest mess:
>In that same vein [of security Glasnost], i offer the following honey danber
>"experiment." (sansfix! if you have this bug, go bug your vendor.)
[hdbworm code follows.]
Yes, this vendor has that bug. :-( Peter will be pleased to know, though, that
someone did a quite exhaustive security cleanup job on uuxqt.c for SVR3.2 BNU,
and this hole was fixed (along with several others). So those who get BNU from
Sun will not have this bug. For those of you with source licenses, upgrade to
SVR3.2. For those of you with binary licenses, upgrade to SVR3.2....
4.3BSD has never had the hdbworm bug, and other UUCP versions are too stupid
to have it. (They don't support the 'R' uux JCL command.)
4.3BSD UUCP and SVR3.2 BNU react quite differently. 4.3BSD runs the job nor-
mally, and only sanity-checks the originator's address if something fails
(that is, it needs to send to the originator). It logs the error, and sends
mail to "hostname!postmaster" instead. SVR3.2 BNU checks the username immedi-
ately after parsing the JCL file; upon finding an illegal character, it just
writes a log message and discards the job.
<csg>
----------------------------------------------------------------------
Subject: Re: ~uucp/.forward
Date: Wed, 23 Nov 88 17:19:51 EST
From: Gene Spafford <spaf@purdue.edu>
[Included here for those interested in what the phage list is all about.--ab]
>From here the view is that this list isn't for posting anything about
security flaws in programs unless a simple fix accompanies it.
I really don't want this to turn into a security mailing list...we've
got enough of those already. This list is going to wind down and go away
before too long if that is what it becomes.
The reason I'm keeping this list at all is to try to talk about some of
the meta-issues: what steps do we take to prevent the next worm? What
reactions are companies having to all this? Etc.
>From the mail I sent out last week:
I see the following topics as being some of the things this list is
appropriate for; other topics may also be suggested:
* How do we prevent future attacks like this?
* What is the best way to publicize seccurity problems and fixes?
* How can we communicate next time there is a problem that
fragments the Internet?
* How has the media covered this event? What can we do to make
future coverage better?
* Can we coordinate some kind of security audit of network software?
Should we? Or should this be left just to Berkeley and vendors?
Although I am interested in the following topics, I think they are
not appropriate for this list:
* What punishment should the "wormer" get?
* What is the $$ amount of damages involved and how do we tell?
* What motivated RTM (allegedly) to do this?
* Was it a wrong thing to do this? (I exclude this topic because
I feel it is incredibly insulting to anyone who uses computers
responsibly. The majority of us feel it was wrong, and this
list is not a place to debate matters of degree.)
--spaf
----------------------------------------------------------------------
From: zardoz!ccicpg!cci632!warper.jhuapl.edu!ll-xn!ucsd!aplvax.jhuapl.edu!trn
Date: Wed, 23 Nov 88 13:35:41 EST
Subject: minimizing the risks of tftpd
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
+::0:0:::
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.}
===============================================================================
Mail replies/comments to -- ARPA: trn@aplcomm.jhuapl.edu
UUCP: {...!}mimsy!aplcomm!trn
----------------------------------------------------------------------
Date: Thu, 24 Nov 88 15:50:44 PST
From: zardoz!cblpf!mark (Mark R Horton +1 614 860 4276)
Subject: Re: ~uucp
Hmm, it's not very often I disagree with Henry Spencer. Makes me wonder
if my own memory is going...
The ~uucp=/usr/spool/uucppublic notion goes back to V7. Referring to ~uucp
from another system via a uucp command is kind of pointless, since you can
say ~ and get the same effect with less effort. But it matters to users on
the same system, since typing "/usr/spool/uucppublic" is a lot of work. I
finally bit the bullet and set a $p in my .profile to get the same effect.
Now that the security problem with having ~uucp=/usr/spool/uucppublic has
been discovered, hopefully the security concerns will override the convenience
issue.
System V comes with ~uucp=/usr/lib/uucp, so that should be no problem on
a properly administered system. But V7 and systems derived from it, such
as 4.2BSD and SunOS should probably move uucp's home directory.
Mark
----------------------------------------------------------------------
From: "Matt Crawford" <matt@oddjob.uchicago.edu>
Subject: Re: ~uucp/.forward
Date: Wed, 23 Nov 88 10:35:37 CST
A friendly neighbor superuser thought that creating a directory
called .rhosts was a safety measure. I created and deleted a file in
it called "\noddjob.uchicago.edu matt\n", and showed him otherwise.
Matt
----------------------------------------------------------------------
From: cher@whutt.att.com
Date: Wed, 23 Nov 88 10:16 EST
Subject: the good of prophylactics
To: arpa!phage@cs.purdue.edu
Subject: the good of prophylactics
> On the other hand I think we have to be cautious about fooling
> ourselves. People are proposing all sorts of prophylactic security
> mechanisms (this one, shadow passwds etc) which I believe is a bad
> thing to stress in general. It seems to be the management of
> insecurity rather than any attempt to create security. Have we really
> given up and just decided to limit the damage? Sounds like a bad idea.
> Also an infinite pit into which we will regret having slipped.
> -Barry Shein, ||Encore||
There does not seem to be an alternative. Since most of the attempts
to make the system secure are based on the Orange Book, and the OB
requires a grand underlying security policy only at higher levels, many
of these attempts are largely tinkering. Even at higher levels, making
a secure system looks like addressing a myriad of separate concerns.
As for stressing little prophylatics: if the peephole approach to security
makes one uncomfortable, one can always devise a grand umbrella principle.
Eg, The Great Principle of the Least Privilege demands that you not
use setuid foo where you can use setuid something-less-powerful-than-foo;
the Great Principle of the Least Knowledge says that the users have no
need to see password encryptions, etc.
Mike Cherepov
----------------------------------------------------------------------
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).
END OF DOCUMENT
| ISSN 1742-948X 01 (Online) | 2004/04/01 | Copyright 2002-2004 securitydigest.org. All rights reserved. |