CIAC Documents FY 1989
ciac-01.386i-authentication
ciac-02.columbus-day-virus
ciac-03.decwindows-ultrix
ciac-04.jerusalem-virus
ciac-05.unix-holes
ciac-06.unix-wall-rwalld
ciac-07.unix-rcp-rdist
ciac-08.sunos-restore
ciac-09.nvir-virus
ciac-10.columbus-day-virus
ciac-11.unix-telnet-trojan-horse
ciac-12.unix-rcp-rdist-patch
ciac-13.mac-ncsa-telnet
ciacfy89.txt All FY89 documents.
________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
ADVISORY NOTICE
________________________________________________________________
COMPUTER SECURITY INFORMATION
Authentication bypass in Sun 386i machines
The login program supplied by Sun for its 386i machines, version 4.0.1 of Sun
OS (SOS), accepts the argument "-n" which bypasses authentication. It was
apparently added in order to allow the Sun program "logintool" to do the
authentication and have login do the housekeeping. This allows a user who
discovers the new argument to the login program to become a root user in
several ways. An example of one method is attached.
A temporary solution is to disable logintool and patch the binary using
the "strings" and "adb"method used last November. Alternatively and more
simly, log in a root and issue the command
chmod 110 /bin/login
Example of login endrun:
---------------------------------------------------
Script started on Tue Apr 11 14:16:25 1989
myhost[1] whoami
oconnor
myhost[2] /bin/login -n root
Login incorrect
login: onceuponatime
No home directory specified in password file! Logging in with home=/
# whoami
root
# who a i
myhost!onceupon ttyp2 Apr 11 14:17
# ^D myhost1[3] ^D
script done on Tue Apr 11 14:17:34 1989
---------------------------------------------------
Sun is presently working on a patch. When it is available, CIAC will
inform you accordingly.
For questions or additional information, please contact
Gene Schultz
CIAC Team Leader
(415) 422-8193 or FTS 532-8193
gschultz%nsspa@icdc.llnl.gov
____________________________________________________
C I A C
Computer Incident Advisory Capability
____________________________________________________
September 8, 1989
Notice of Columbus Day Virus
Affecting IBM PCs and PC Clones
The DOE Computer Incident Advisory Capability (CIAC) has learned
that there is a Columbus Day Virus which may attack MS-DOS (PC-
DOS) personal computers on or after October 12 or October 13, 1989.
Note that October 13 is a Friday the thirteenth. You should make the
information in this notice available to appropriate personnel at your
site so that the virus can be detected and eradicated.
The Columbus Day Virus has been isolated and may actually be one
of a series of related viruses. It most closely resembles the DataCrime
Virus. Contrary to speculation in a recent Federal Computing Weekly
article, however, the Columbus Day Virus does not appear to be
closely related to the Icelandic or West German virus. The Columbus
Day Virus searches through the DOS directory for .COM files other
than COMMAND.COM. It attaches to the end of a .COM file, which
increases the size of the file by 1168 bytes. The virus infects any
given .COM file only once. However, it will infect any uninfected .COM
file that it encounters. If the virus executes, it will display the
message:
DATACRIME VIRUS
RELEASED:l MARCH 1989
and then do a low-level format on track zero. Since this is the boot
area of the disk, the hard disk will be unbootable.
Detection of this virus is difficult because ASCII strings in the virus
code are encrypted. Therefore, utilities that search files for particular
ASCII strings are useless. There are two methods you can use to
detect this virus. The first method is to check for a size increase of
1168 bytes in .COM files. Another possible method is to use
VIRUSCAN*, (see below) which should report the existence of this
virus as well as several other viruses. If a machine is infected, users
must copy over all infected .COM files using their original .COM files.
This must be accomplished at one sitting to prevent re-infection. You
should also examine backups to see if they are infected. You should
repeat whatever detection method you decide to use every time you
load a new .COM file or database into your PC or PC clone.
If the boot sector is destroyed, it can be restored with Disk Doctor, a
utility in Norton Utilities Version 4.5 (Advanced Edition). Note that a
restoration is possible only if the Disk Doctor utility had been
previously run.
The DOE Center for Computer Security at Los Alamos has recently
published a pamphlet, "Computer Viruses and the Personal Computer
User" (CCS-89-03). CIAC recommends that you read and follow the
excellent guidelines contained in this pamphlet .
Because VIRUSCAN is produced and distributed by a commercial
developer, CIAC cannot at this time send copies of this software
directly to you. To obtain a copy of VIRUSCAN, you need to send $15
with your name, address and phone number to:
McAfee Associates
4423 Cheeney St.
Santa Clara, CA 95054
Phone: (408) 988-3832
For further information contact David S. Brown at CIAC. David's
phone is (415) 4239878 or (FTS) 533-9878. He can also be reached
at the CIAC number, (415) 422-8193 or (FTS) 532-8193. David's e-
mail address is:
brown@pantera.llnl.gov
* - The University of California neither endorses VIRUSCAN nor
guarantees the effectiveness of this software package. CIAC will test
this package in the near future to determine whether it provides
adequate detection of the Columbus Day virus.
____________________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
____________________________________________________________________________
April 14, 1989
The Computer Incident Advisory Capability (CIAC) has learned of a
vulnerability in DECWindows running under ULTRIX. There is a
pseudofile, /dev/mem, which contains passwords. Passwords can be
compromised if someone accesses this pseudofile. CIAC will advise
you of a workaround or fix when either becomes available.
Gene Schultz
CIAC Manager
Lawrence Livermore National Laboratory
P.O. Box 808, L-195
Livermore, CA 94550
(415) 422-8193 or (FTS) 532-8193
gschultz%nsspa@icdc.llnl.gov
____________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
____________________________________________________________________
June 5, 1989
The Computer Incident Advisory Capability (CIAC) has been helping
several sites deal with a new strain of the Jerusalem/Israeli/
Friday the 13th virus which infects IBM PC's and PC clones. This
new strain, the "Little Black Box" virus, causes a small black box
to appear in the lower left quadrant of the scrren. The virus adds
1808 bytes to an .exe file every time an application is executed
until the executable image is too large to fit into memory or disk
space is exhausted. This causes poor system performance. This
virus will also add 1813 byes to .com files, one at a time. This
causes parity errors which disrupt EGA and CGA screen.
This "Little Black Box" virus does not destroy files. It does,
however, spread quickly. The most common way viruses are spread
is through exchanging removable media. Please advise personnel at
your site to follow your procedures which prevent virus infections.
CIAC now has immunization, detection, and eradication programs for
the "Little Black Box" virus. To obtain a copy, contact:
Gene Schultz, CIAC Manager
Lawrence Livermore National Laboratory
P.O. Box 808, L-195
Livermore, CA 94550
(415) 422-8193 or (FTS) 532-8193
gschultz%nsspa@icdc.llnl.gov
________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
ADVISORY NOTICE
________________________________________________________________
Security Holes in UNIX Systems
The DOE Computer Incident Advisory Capability (CIAC) at LLNL has learned
that there are two security holes which leave certain systems running the
UNIX Operating System vulnerable to intrusion. The holes, when used together
in a very specific scenario, permit an intruder to attack UNIX systems
over the Internet and other pathways, and to assume superuser privileges.
Therefore, these vulnerabilities constitute a highly severe threat. Sun
systems running SunOS 3.x and 4.0 are susceptible; the hole may exist in
other versions of the UNIX operating system as well. A brief description
of the holes follow:
1. There is a long-known hole in tftp, the user interface to the
Internet TFTP (Trivial File Transfer Protocol). This hole allows
any user, without first logging in, to read any readable file and
to write any writable file on a remote system via Internet. This
hole exists in SunOS 3.x, but has been fixed in SunOS 4.0.
To determine whether this hole affects a system, do the following:
Enter tftp local_testing_system at the UNIX prompt and follow
with a carriage return. For example,
% tftp styx <RET>
The system should answer with the tftp prompt:
tftp>
Enter the following at the prompt:
tftp> get /etc/passwd stolen_pw
If "Error code 1: File not found" appears, the tested system is
safe from remote attacks. However, it may still be susceptible to
local attacks.
2. There are holes in rwalld (the network rwall server daemon) and
wall (write to all users). The command "wall" writes to filenames
encoded within /etc/utmp. You are vulnerable to this hole if
/etc/utmp is world and/or group writable. In essence, an intruder
can use this hole to write on any file on the computer system.
Any UNIX machine which runs a windowing system is likely to have the
privileges which create the described vulnerabilities. The presence of
an intruder who exploits these holes is difficult to detect. It is our
understanding that knowledge of these holes has been distributed widely
within the hacker community. It is advisable, based on your vulnerability,
to take appropriate action for your site.
CIAC is currently working with Sun Microsystems and DARPA's Computer
Emergency Response Team (CERT) to eliminate these vulnerabilities as
quickly as possible. You will be notified when a patch is available. For
further information, contact CIAC at (415) 422-8193 or (FTS) 532-8193, or
send e-mail to gschultz%nsspa@icdc.llnl.gov.
________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
ADVISORY NOTICE
________________________________________________________________
Notice of Availability of Patch for rwalld/wall
Nearly one month ago, you received a bulletin from the Center for Computer
Security in Los Alamos, in which you were informed of two security holes in the
UNIX operating system. These holes are in tftp and rwalld. The Computer
Incident Advisory Capability (CIAC) at LLNL has been advised that Sun
Microsystems has a patch available for rwalld/wall. You must obtain this patch
directly from Sun. To obtain this patch, call Trevor Goldfisher at Sun
Microsystems, (415) 336-4971, or send email to
trevorg@sun.COM
Sun is continuing to work on the tftp hole. However, patching rwalld/wall
substantially reduces the potential to exploit the tftp hole.
All operations offices were notified of the availability of this security
patch two weeks ago. Not every CPPM has been contacted, however, so I am
sending this notice to every CPPM. Please ignore this notice if you have
already been contacted by your operations office.
Gene Schultz
CIAC Team Leader
(415) 422-8193 or FTS 532-8193
gschultz%nsspa@icdc.llnl.gov
________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
ADVISORY NOTICE
________________________________________________________________
NOTICE OF VULNERABILITY INVOLVING RCP AND RDIST
The DOE Computer Incident Advisory Capability (CIAC) has learned of a
UNIX security problem involving rcp and rdist in 4.3BSD, 4.3BSD-tahoe,
and all versions of UNIX using BSD networking code, as well as SunOS (all
versions). This vulnerability allows someone to overwrite system files
without being detected.
Because this problem has potentially serious consequences, CIAC recommends
that you install a patch to correct the problems with rcp and rdist. A patch
is now available for BSD systems. CIAC will send this patch to you via e-mail
if you contact:
Gene Schultz, CIAC Manager
gschultz%nsspa@icdc.llnl.gov
(415) 422-8193 or (FTS) 532-8193
or send e-mail to:
ciac@tiger.llnl.gov
Although there are no SunOS workarounds currently available for rcp and rdist,
Sun is developing a patch. If you would like to be notified when this patch
is available, please contact CIAC.
------- Forwarded Message
Date: Thu, 25 May 89 15:33:48 GMT
>From: bostic@okeeffe.Berkeley.EDU (Keith Bostic)
Message-Id: <8905251533.AA15064@okeeffe.Berkeley.EDU>
To: cert@sei.cmu.edu
Subject: V1.82 (Rcp/rdist security patch)
Subject: Rcp/rdist security patch
Index: bin/rcp.c 4.3BSD
Index: ucb/rdist/server.c 4.3BSD
Description:
There's a security problem associated with rcp and rdist
in the 4.3BSD, 4.3BSD-tahoe, and first BSD networking
distributions.
Fix:
Replace your current bin/rcp.c with the attached rcp.c.
Patch the server.c module in your current rdist with the
attached patched. Recompile and re-install.
# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file". Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# rcp.c
# rdist.server.c.diff
#
echo x - rcp.c
sed 's/^X//' >rcp.c << 'END-of-rcp.c'
X/*
X * Copyright (c) 1983 The Regents of the University of California.
X * All rights reserved.
X *
X * Redistribution and use in source and binary forms are permitted
X * provided that the above copyright notice and this paragraph are
X * duplicated in all such forms and that any documentation,
X * advertising materials, and other materials related to such
X * distribution and use acknowledge that the software was developed
X * by the University of California, Berkeley. The name of the
X * University may not be used to endorse or promote products derived
X * from this software without specific prior written permission.
X * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
X * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
X * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
X */
X
X#ifndef lint
Xchar copyright[] =
X"@(#) Copyright (c) 1983 The Regents of the University of California.\n\
X All rights reserved.\n";
X#endif /* not lint */
X
X#ifndef lint
Xstatic char sccsid[] = "@(#)rcp.c 5.20 (Berkeley) 5/23/89";
X#endif /* not lint */
X
X/*
X * rcp
X */
X#include <sys/param.h>
X#include <sys/file.h>
X#include <sys/stat.h>
X#include <sys/time.h>
X#include <sys/ioctl.h>
X#include <sys/dir.h>
X#include <sys/signal.h>
X#include <netinet/in.h>
X#include <pwd.h>
X#include <netdb.h>
X#include <errno.h>
X#include <string.h>
X#include <stdio.h>
X#include <ctype.h>
X#include "pathnames.h"
X
X#ifdef KERBEROS
X#include <kerberos/krb.h>
X
Xchar krb_realm[REALM_SZ];
Xint use_kerberos = 1, encrypt = 0;
XCREDENTIALS cred;
XKey_schedule schedule;
X#endif
X
Xextern int errno;
Xextern char *sys_errlist[];
Xstruct passwd *pwd;
Xint errs, pflag, port, rem, userid;
Xint iamremote, iamrecursive, targetshouldbedirectory;
X
X#define CMDNEEDS 20
Xchar cmd[CMDNEEDS]; /* must hold "rcp -r -p -d\0" */
X
Xtypedef struct _buf {
X int cnt;
X char *buf;
X} BUF;
X
Xmain(argc, argv)
X int argc;
X char **argv;
X{
X extern int optind;
X struct servent *sp;
X int ch, fflag, tflag;
X char *targ, *colon();
X struct passwd *getpwuid();
X int lostconn();
X
X#ifdef KERBEROS
X sp = getservbyname("kshell", "tcp");
X if (sp == NULL) {
X use_kerberos = 0;
X old_warning("kshell service unknown");
X sp = getservbyname("kshell", "tcp");
X }
X#else
X sp = getservbyname("shell", "tcp");
X#endif
X if (!sp) {
X (void)fprintf(stderr, "rcp: shell/tcp: unknown service\n");
X exit(1);
X }
X port = sp->s_port;
X
X if (!(pwd = getpwuid(userid = getuid()))) {
X (void)fprintf(stderr, "rcp: unknown user %d.\n", userid);
X exit(1);
X }
X
X fflag = tflag = 0;
X while ((ch = getopt(argc, argv, "dfkprtx")) != EOF)
X switch(ch) {
X case 'd':
X targetshouldbedirectory = 1;
X break;
X case 'f': /* "from" */
X fflag = 1;
X break;
X#ifdef KERBEROS
X case 'k':
X strncpy(krb_realm, ++argv, REALM_SZ);
X break;
X#endif
X case 'p': /* preserve access/mod times */
X ++pflag;
X break;
X case 'r':
X ++iamrecursive;
X break;
X case 't': /* "to" */
X tflag = 1;
X break;
X#ifdef KERBEROS
X case 'x':
X encrypt = 1;
X des_set_key(cred.session, schedule);
X break;
X#endif
X case '?':
X default:
X usage();
X }
X argc -= optind;
X argv += optind;
X
X if (fflag) {
X iamremote = 1;
X (void)response();
X (void)setuid(userid);
X source(argc, argv);
X exit(errs);
X }
X
X if (tflag) {
X iamremote = 1;
X (void)setuid(userid);
X sink(argc, argv);
X exit(errs);
X }
X
X if (argc < 2)
X usage();
X if (argc > 2)
X targetshouldbedirectory = 1;
X
X rem = -1;
X (void)sprintf(cmd, "rcp%s%s%s", iamrecursive ? " -r" : "",
X pflag ? " -p" : "", targetshouldbedirectory ? " -d" : "");
X
X (void)signal(SIGPIPE, lostconn);
X
X if (targ = colon(argv[argc - 1]))
X toremote(targ, argc, argv);
X else {
X tolocal(argc, argv);
X if (targetshouldbedirectory)
X verifydir(argv[argc - 1]);
X }
X exit(errs);
X}
X
Xtoremote(targ, argc, argv)
X char *targ;
X int argc;
X char **argv;
X{
X int i;
X char *bp, *host, *src, *suser, *thost, *tuser;
X char *colon(), *malloc();
X
X *targ++ = 0;
X if (*targ == 0)
X targ = ".";
X
X if (thost = index(argv[argc - 1], '@')) {
X *thost++ = 0;
X tuser = argv[argc - 1];
X if (*tuser == '\0')
X tuser = NULL;
X else if (!okname(tuser))
X exit(1);
X } else {
X thost = argv[argc - 1];
X tuser = NULL;
X }
X
X for (i = 0; i < argc - 1; i++) {
X src = colon(argv[i]);
X if (src) { /* remote to remote */
X *src++ = 0;
X if (*src == 0)
X src = ".";
X host = index(argv[i], '@');
X if (!(bp = malloc((u_int)(strlen(_PATH_RSH) +
X strlen(argv[i]) + strlen(src) +
X strlen(tuser) + strlen(thost) +
X strlen(targ)) + CMDNEEDS + 20)))
X nospace();
X if (host) {
X *host++ = 0;
X suser = argv[i];
X if (*suser == '\0')
X suser = pwd->pw_name;
X else if (!okname(suser))
X continue;
X (void)sprintf(bp,
X "%s %s -l %s -n %s %s '%s%s%s:%s'",
X _PATH_RSH, host, suser, cmd, src,
X tuser ? tuser : "", tuser ? "@" : "",
X thost, targ);
X } else
X (void)sprintf(bp, "%s %s -n %s %s '%s%s%s:%s'",
X _PATH_RSH, argv[i], cmd, src,
X tuser ? tuser : "", tuser ? "@" : "",
X thost, targ);
X (void)susystem(bp);
X (void)free(bp);
X } else { /* local to remote */
X if (rem == -1) {
X if (!(bp = malloc((u_int)strlen(targ) +
X CMDNEEDS + 20)))
X nospace();
X (void)sprintf(bp, "%s -t %s", cmd, targ);
X host = thost;
X#ifdef KERBEROS
X if (use_kerberos)
X kerberos(bp,
X tuser ? tuser : pwd->pw_name);
X else
X#endif
X rem = rcmd(&host, port, pwd->pw_name,
X tuser ? tuser : pwd->pw_name,
X bp, 0);
X if (rem < 0)
X exit(1);
X if (response() < 0)
X exit(1);
X (void)free(bp);
X (void)setuid(userid);
X }
X source(1, argv+i);
X }
X }
X}
X
Xtolocal(argc, argv)
X int argc;
X char **argv;
X{
X int i;
X char *bp, *host, *src, *suser;
X char *colon(), *malloc();
X
X for (i = 0; i < argc - 1; i++) {
X if (!(src = colon(argv[i]))) { /* local to local */
X if (!(bp = malloc((u_int)(strlen(_PATH_CP) +
X strlen(argv[i]) + strlen(argv[argc - 1])) + 20)))
X nospace();
X (void)sprintf(bp, "%s%s%s %s %s", _PATH_CP,
X iamrecursive ? " -r" : "", pflag ? " -p" : "",
X argv[i], argv[argc - 1]);
X (void)susystem(bp);
X (void)free(bp);
X continue;
X }
X *src++ = 0;
X if (*src == 0)
X src = ".";
X host = index(argv[i], '@');
X if (host) {
X *host++ = 0;
X suser = argv[i];
X if (*suser == '\0')
X suser = pwd->pw_name;
X else if (!okname(suser))
X continue;
X } else {
X host = argv[i];
X suser = pwd->pw_name;
X }
X if (!(bp = malloc((u_int)(strlen(src)) + CMDNEEDS + 20)))
X nospace();
X (void)sprintf(bp, "%s -f %s", cmd, src);
X#ifdef KERBEROS
X if (use_kerberos)
X kerberos(bp, suser);
X else
X#endif
X rem = rcmd(&host, port, pwd->pw_name, suser, bp, 0);
X (void)free(bp);
X if (rem < 0)
X continue;
X (void)setreuid(0, userid);
X sink(1, argv + argc - 1);
X (void)setreuid(userid, 0);
X (void)close(rem);
X rem = -1;
X }
X}
X
X#ifdef KERBEROS
Xkerberos(bp, user)
X char *bp, *user;
X{
X struct servent *sp;
X char *host;
X
Xagain: rem = KSUCCESS;
X if (krb_realm[0] == '\0')
X rem = krb_get_lrealm(krb_realm, 1);
X if (rem == KSUCCESS) {
X if (encrypt)
X rem = krcmd_mutual(&host, port, user, bp, 0,
X krb_realm, &cred, schedule);
X else
X rem = krcmd(&host, port, user, bp, 0, krb_realm);
X } else {
X (void)fprintf(stderr,
X "rcp: error getting local realm %s\n", krb_err_txt[rem]);
X exit(1);
X }
X if (rem < 0 && errno == ECONNREFUSED) {
X use_kerberos = 0;
X old_warning("remote host doesn't support Kerberos");
X sp = getservbyname("shell", "tcp");
X if (sp == NULL) {
X (void)fprintf(stderr,
X "rcp: unknown service shell/tcp\n");
X exit(1);
X }
X port = sp->s_port;
X goto again;
X }
X}
X#endif /* KERBEROS */
X
Xverifydir(cp)
X char *cp;
X{
X struct stat stb;
X
X if (stat(cp, &stb) >= 0) {
X if ((stb.st_mode & S_IFMT) == S_IFDIR)
X return;
X errno = ENOTDIR;
X }
X error("rcp: %s: %s.\n", cp, sys_errlist[errno]);
X exit(1);
X}
X
Xchar *
Xcolon(cp)
X register char *cp;
X{
X for (; *cp; ++cp) {
X if (*cp == ':')
X return(cp);
X if (*cp == '/')
X return(0);
X }
X return(0);
X}
X
Xokname(cp0)
X char *cp0;
X{
X register char *cp = cp0;
X register int c;
X
X do {
X c = *cp;
X if (c & 0200)
X goto bad;
X if (!isalpha(c) && !isdigit(c) && c != '_' && c != '-')
X goto bad;
X } while (*++cp);
X return(1);
Xbad:
X (void)fprintf(stderr, "rcp: invalid user name %s\n", cp0);
X return(0);
X}
X
Xsusystem(s)
X char *s;
X{
X int status, pid, w;
X register int (*istat)(), (*qstat)();
X
X if ((pid = vfork()) == 0) {
X (void)setuid(userid);
X execl(_PATH_BSHELL, "sh", "-c", s, (char *)0);
X _exit(127);
X }
X istat = signal(SIGINT, SIG_IGN);
X qstat = signal(SIGQUIT, SIG_IGN);
X while ((w = wait(&status)) != pid && w != -1)
X ;
X if (w == -1)
X status = -1;
X (void)signal(SIGINT, istat);
X (void)signal(SIGQUIT, qstat);
X return(status);
X}
X
Xsource(argc, argv)
X int argc;
X char **argv;
X{
X struct stat stb;
X static BUF buffer;
X BUF *bp;
X off_t i;
X int x, readerr, f, amt;
X char *last, *name, buf[BUFSIZ];
X BUF *allocbuf();
X
X for (x = 0; x < argc; x++) {
X name = argv[x];
X if ((f = open(name, O_RDONLY, 0)) < 0) {
X error("rcp: %s: %s\n", name, sys_errlist[errno]);
X continue;
X }
X if (fstat(f, &stb) < 0)
X goto notreg;
X switch (stb.st_mode&S_IFMT) {
X
X case S_IFREG:
X break;
X
X case S_IFDIR:
X if (iamrecursive) {
X (void)close(f);
X rsource(name, &stb);
X continue;
X }
X /* FALLTHROUGH */
X default:
Xnotreg: (void)close(f);
X error("rcp: %s: not a plain file\n", name);
X continue;
X }
X last = rindex(name, '/');
X if (last == 0)
X last = name;
X else
X last++;
X if (pflag) {
X /*
X * Make it compatible with possible future
X * versions expecting microseconds.
X */
X (void)sprintf(buf, "T%ld 0 %ld 0\n", stb.st_mtime,
X stb.st_atime);
X (void)write(rem, buf, strlen(buf));
X if (response() < 0) {
X (void)close(f);
X continue;
X }
X }
X (void)sprintf(buf, "C%04o %ld %s\n", stb.st_mode&07777,
X stb.st_size, last);
X (void)write(rem, buf, strlen(buf));
X if (response() < 0) {
X (void)close(f);
X continue;
X }
X if ((bp = allocbuf(&buffer, f, BUFSIZ)) == 0) {
X (void)close(f);
X continue;
X }
X readerr = 0;
X for (i = 0; i < stb.st_size; i += bp->cnt) {
X amt = bp->cnt;
X if (i + amt > stb.st_size)
X amt = stb.st_size - i;
X if (readerr == 0 && read(f, bp->buf, amt) != amt)
X readerr = errno;
X (void)write(rem, bp->buf, amt);
X }
X (void)close(f);
X if (readerr == 0)
X (void)write(rem, "", 1);
X else
X error("rcp: %s: %s\n", name, sys_errlist[readerr]);
X (void)response();
X }
X}
X
Xrsource(name, statp)
X char *name;
X struct stat *statp;
X{
X DIR *d;
X struct direct *dp;
X char *last, *vect[1], path[MAXPATHLEN];
X
X if (!(d = opendir(name))) {
X error("rcp: %s: %s\n", name, sys_errlist[errno]);
X return;
X }
X last = rindex(name, '/');
X if (last == 0)
X last = name;
X else
X last++;
X if (pflag) {
X (void)sprintf(path, "T%ld 0 %ld 0\n", statp->st_mtime,
X statp->st_atime);
X (void)write(rem, path, strlen(path));
X if (response() < 0) {
X closedir(d);
X return;
X }
X }
X (void)sprintf(path, "D%04o %d %s\n", statp->st_mode&07777, 0, last);
X (void)write(rem, path, strlen(path));
X if (response() < 0) {
X closedir(d);
X return;
X }
X while (dp = readdir(d)) {
X if (dp->d_ino == 0)
X continue;
X if (!strcmp(dp->d_name, ".") || !strcmp(dp->d_name, ".."))
X continue;
X if (strlen(name) + 1 + strlen(dp->d_name) >= MAXPATHLEN - 1) {
X error("%s/%s: name too long.\n", name, dp->d_name);
X continue;
X }
X (void)sprintf(path, "%s/%s", name, dp->d_name);
X vect[0] = path;
X source(1, vect);
X }
X closedir(d);
X (void)write(rem, "E\n", 2);
X (void)response();
X}
X
Xresponse()
X{
X register char *cp;
X char ch, resp, rbuf[BUFSIZ];
X
X if (read(rem, &resp, sizeof(resp)) != sizeof(resp))
X lostconn();
X
X cp = rbuf;
X switch(resp) {
X case 0: /* ok */
X return(0);
X default:
X *cp++ = resp;
X /* FALLTHROUGH */
X case 1: /* error, followed by err msg */
X case 2: /* fatal error, "" */
X do {
X if (read(rem, &ch, sizeof(ch)) != sizeof(ch))
X lostconn();
X *cp++ = ch;
X } while (cp < &rbuf[BUFSIZ] && ch != '\n');
X
X if (!iamremote)
X (void)write(2, rbuf, cp - rbuf);
X ++errs;
X if (resp == 1)
X return(-1);
X exit(1);
X }
X /*NOTREACHED*/
X}
X
Xlostconn()
X{
X if (!iamremote)
X (void)fprintf(stderr, "rcp: lost connection\n");
X exit(1);
X}
X
Xsink(argc, argv)
X int argc;
X char **argv;
X{
X register char *cp;
X static BUF buffer;
X struct stat stb;
X struct timeval tv[2];
X BUF *bp, *allocbuf();
X off_t i, j;
X char ch, *targ, *why;
X int amt, count, exists, first, mask, mode;
X int ofd, setimes, size, targisdir, wrerr;
X char *np, *vect[1], buf[BUFSIZ], *malloc();
X
X#define atime tv[0]
X#define mtime tv[1]
X#define SCREWUP(str) { why = str; goto screwup; }
X
X setimes = targisdir = 0;
X mask = umask(0);
X if (!pflag)
X (void)umask(mask);
X if (argc != 1) {
X error("rcp: ambiguous target\n");
X exit(1);
X }
X targ = *argv;
X if (targetshouldbedirectory)
X verifydir(targ);
X (void)write(rem, "", 1);
X if (stat(targ, &stb) == 0 && (stb.st_mode & S_IFMT) == S_IFDIR)
X targisdir = 1;
X for (first = 1;; first = 0) {
X cp = buf;
X if (read(rem, cp, 1) <= 0)
X return;
X if (*cp++ == '\n')
X SCREWUP("unexpected <newline>");
X do {
X if (read(rem, &ch, sizeof(ch)) != sizeof(ch))
X SCREWUP("lost connection");
X *cp++ = ch;
X } while (cp < &buf[BUFSIZ - 1] && ch != '\n');
X *cp = 0;
X
X if (buf[0] == '\01' || buf[0] == '\02') {
X if (iamremote == 0)
X (void)write(2, buf + 1, strlen(buf + 1));
X if (buf[0] == '\02')
X exit(1);
X errs++;
X continue;
X }
X if (buf[0] == 'E') {
X (void)write(rem, "", 1);
X return;
X }
X
X if (ch == '\n')
X *--cp = 0;
X
X#define getnum(t) (t) = 0; while (isdigit(*cp)) (t) = (t) * 10 + (*cp++ - '0');
X cp = buf;
X if (*cp == 'T') {
X setimes++;
X cp++;
X getnum(mtime.tv_sec);
X if (*cp++ != ' ')
X SCREWUP("mtime.sec not delimited");
X getnum(mtime.tv_usec);
X if (*cp++ != ' ')
X SCREWUP("mtime.usec not delimited");
X getnum(atime.tv_sec);
X if (*cp++ != ' ')
X SCREWUP("atime.sec not delimited");
X getnum(atime.tv_usec);
X if (*cp++ != '\0')
X SCREWUP("atime.usec not delimited");
X (void)write(rem, "", 1);
X continue;
X }
X if (*cp != 'C' && *cp != 'D') {
X /*
X * Check for the case "rcp remote:foo\* local:bar".
X * In this case, the line "No match." can be returned
X * by the shell before the rcp command on the remote is
X * executed so the ^Aerror_message convention isn't
X * followed.
X */
X if (first) {
X error("%s\n", cp);
X exit(1);
X }
X SCREWUP("expected control record");
X }
X mode = 0;
X for (++cp; cp < buf + 5; cp++) {
X if (*cp < '0' || *cp > '7')
X SCREWUP("bad mode");
X mode = (mode << 3) | (*cp - '0');
X }
X if (*cp++ != ' ')
X SCREWUP("mode not delimited");
X size = 0;
X while (isdigit(*cp))
X size = size * 10 + (*cp++ - '0');
X if (*cp++ != ' ')
X SCREWUP("size not delimited");
X if (targisdir) {
X static char *namebuf;
X static int cursize;
X int need;
X
X need = strlen(targ) + strlen(cp) + 250;
X if (need > cursize) {
X if (!(namebuf = malloc((u_int)need)))
X error("out of memory\n");
X }
X (void)sprintf(namebuf, "%s%s%s", targ,
X *targ ? "/" : "", cp);
X np = namebuf;
X }
X else
X np = targ;
X exists = stat(np, &stb) == 0;
X if (buf[0] == 'D') {
X if (exists) {
X if ((stb.st_mode&S_IFMT) != S_IFDIR) {
X errno = ENOTDIR;
X goto bad;
X }
X if (pflag)
X (void)chmod(np, mode);
X } else if (mkdir(np, mode) < 0)
X goto bad;
X vect[0] = np;
X sink(1, vect);
X if (setimes) {
X setimes = 0;
X if (utimes(np, tv) < 0)
X error("rcp: can't set times on %s: %s\n",
X np, sys_errlist[errno]);
X }
X continue;
X }
X if ((ofd = open(np, O_WRONLY|O_CREAT, mode)) < 0) {
Xbad: error("rcp: %s: %s\n", np, sys_errlist[errno]);
X continue;
X }
X if (exists && pflag)
X (void)fchmod(ofd, mode);
X (void)write(rem, "", 1);
X if ((bp = allocbuf(&buffer, ofd, BUFSIZ)) == 0) {
X (void)close(ofd);
X continue;
X }
X cp = bp->buf;
X count = 0;
X wrerr = 0;
X for (i = 0; i < size; i += BUFSIZ) {
X amt = BUFSIZ;
X if (i + amt > size)
X amt = size - i;
X count += amt;
X do {
X j = read(rem, cp, amt);
X if (j <= 0) {
X error("rcp: %s\n",
X j ? sys_errlist[errno] :
X "dropped connection");
X exit(1);
X }
X amt -= j;
X cp += j;
X } while (amt > 0);
X if (count == bp->cnt) {
X if (wrerr == 0 &&
X write(ofd, bp->buf, count) != count)
X wrerr++;
X count = 0;
X cp = bp->buf;
X }
X }
X if (count != 0 && wrerr == 0 &&
X write(ofd, bp->buf, count) != count)
X wrerr++;
X if (ftruncate(ofd, size))
X error("rcp: can't truncate %s: %s\n", np,
X sys_errlist[errno]);
X (void)close(ofd);
X (void)response();
X if (setimes) {
X setimes = 0;
X if (utimes(np, tv) < 0)
X error("rcp: can't set times on %s: %s\n",
X np, sys_errlist[errno]);
X }
X if (wrerr)
X error("rcp: %s: %s\n", np, sys_errlist[errno]);
X else
X (void)write(rem, "", 1);
X }
Xscrewup:
X error("rcp: protocol screwup: %s\n", why);
X exit(1);
X}
X
XBUF *
Xallocbuf(bp, fd, blksize)
X BUF *bp;
X int fd, blksize;
X{
X struct stat stb;
X int size;
X char *malloc();
X
X if (fstat(fd, &stb) < 0) {
X error("rcp: fstat: %s\n", sys_errlist[errno]);
X return(0);
X }
X size = roundup(stb.st_blksize, blksize);
X if (size == 0)
X size = blksize;
X if (bp->cnt < size) {
X if (bp->buf != 0)
X free(bp->buf);
X bp->buf = (char *)malloc((u_int)size);
X if (!bp->buf) {
X error("rcp: malloc: out of memory\n");
X return(0);
X }
X }
X bp->cnt = size;
X return(bp);
X}
X
X/* VARARGS1 */
Xerror(fmt, a1, a2, a3)
X char *fmt;
X int a1, a2, a3;
X{
X static FILE *fp;
X
X ++errs;
X if (!fp && !(fp = fdopen(rem, "w")))
X return;
X (void)fprintf(fp, "%c", 0x01);
X (void)fprintf(fp, fmt, a1, a2, a3);
X (void)fflush(fp);
X if (!iamremote)
X (void)fprintf(stderr, fmt, a1, a2, a3);
X}
X
Xnospace()
X{
X (void)fprintf(stderr, "rcp: out of memory.\n");
X exit(1);
X}
X
X#ifdef KERBEROS
Xold_warning(str)
X char *str;
X{
X (void)fprintf(stderr, "rcp: warning: %s, using standard rcp\n", str);
X}
X#endif
X
Xusage()
X{
X#ifdef KERBEROS
X (void)fprintf(stderr, "%s\n\t%s\n",
X "usage: rcp [-k realm] [-px] f1 f2",
X "or: rcp [-k realm] [-rpx] f1 ... fn directory");
X#else
X (void)fprintf(stderr,
X "usage: rcp [-p] f1 f2; or: rcp [-rp] f1 ... fn directory\n");
X#endif
X exit(1);
X}
END-of-rcp.c
echo x - rdist.server.c.diff
sed 's/^X//' >rdist.server.c.diff << 'END-of-rdist.server.c.diff'
X*** old_server.c Wed Jun 29 20:19:34 1988
X--- server.c Wed May 24 20:17:51 1989
X***************
X*** 1369,1384 ****
X char *fmt;
X int a1, a2, a3;
X {
X! nerrs++;
X! strcpy(buf, "\1rdist: ");
X! (void) sprintf(buf+8, fmt, a1, a2, a3);
X! if (!iamremote) {
X fflush(stdout);
X! (void) write(2, buf+1, strlen(buf+1));
X! } else
X! (void) write(rem, buf, strlen(buf));
X! if (lfp != NULL)
X! (void) fwrite(buf+1, 1, strlen(buf+1), lfp);
X }
X
X /*VARARGS1*/
X--- 1369,1395 ----
X char *fmt;
X int a1, a2, a3;
X {
X! static FILE *fp;
X!
X! ++nerrs;
X! if (!fp && !(fp = fdopen(rem, "w")))
X! return;
X! if (iamremote) {
X! (void)fprintf(fp, "%crdist: ", 0x01);
X! (void)fprintf(fp, fmt, a1, a2, a3);
X! fflush(fp);
X! }
X! else {
X fflush(stdout);
X! (void)fprintf(stderr, "rdist: ");
X! (void)fprintf(stderr, fmt, a1, a2, a3);
X! fflush(stderr);
X! }
X! if (lfp != NULL) {
X! (void)fprintf(lfp, "rdist: ");
X! (void)fprintf(lfp, fmt, a1, a2, a3);
X! fflush(lfp);
X! }
X }
X
X /*VARARGS1*/
X***************
X*** 1386,1401 ****
X char *fmt;
X int a1, a2, a3;
X {
X! nerrs++;
X! strcpy(buf, "\2rdist: ");
X! (void) sprintf(buf+8, fmt, a1, a2, a3);
X! if (!iamremote) {
X fflush(stdout);
X! (void) write(2, buf+1, strlen(buf+1));
X! } else
X! (void) write(rem, buf, strlen(buf));
X! if (lfp != NULL)
X! (void) fwrite(buf+1, 1, strlen(buf+1), lfp);
X cleanup();
X }
X
X--- 1397,1423 ----
X char *fmt;
X int a1, a2, a3;
X {
X! static FILE *fp;
X!
X! ++nerrs;
X! if (!fp && !(fp = fdopen(rem, "w")))
X! return;
X! if (iamremote) {
X! (void)fprintf(fp, "%crdist: ", 0x02);
X! (void)fprintf(fp, fmt, a1, a2, a3);
X! fflush(fp);
X! }
X! else {
X fflush(stdout);
X! (void)fprintf(stderr, "rdist: ");
X! (void)fprintf(stderr, fmt, a1, a2, a3);
X! fflush(stderr);
X! }
X! if (lfp != NULL) {
X! (void)fprintf(lfp, "rdist: ");
X! (void)fprintf(lfp, fmt, a1, a2, a3);
X! fflush(lfp);
X! }
X cleanup();
X }
X
END-of-rdist.server.c.diff
exit
________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
ADVISORY NOTICE
________________________________________________________________
Announcement of Vulnerability in the SunOS Restore Utility
The Computer Incident Advisory Capability (CIAC) has learned of a vulnerability
in SunOS. This vulnerability is in the restore utility. Because restore is
setuid to root, it allows an ordinary user to obtain unauthorized privileges.
This vulnerability is found in all SunOS 4.x systems (4.0, 4.0.1, and 4.0.3).
This vulnerability can, however, be exploited by only users who have an account
on a SunOS 4.x system.
Sun Microsystems is aware of this vulnerability (Sun Bug 1019265) and is
developing a permanent solution in a future SunOS release. However, until
this fix is available, you should install one of two temporary fixes:
Temporary Solution 1: Make restore non-setuid, using the following
workaround:
chmod 750 /usr/etc/restore
This solution is appropriate for systems that do restore locally and uses
the root account to do restores. It eliminates the vulnerability in restore.
However, in addition to making store non-setuid, this solution makes restore
unreadable and non-executable by ordinary (non-root) users, and restricts the
use of remote restore by these users. For example, with SunOS, a user who is
not root cannot get a privileged port. If temporary solution 1 has been
implemented, an ordinary user who requests a remote tape drive to do restore
would discover that restore would be unable to obtain a privileged port.
Therefore, the remote tape drive would not work.
Temporary Solution 2: Using the following workaround:
cd /usr/etc
chgrp operator restore
chmod 4550 restore
You should use this solution if you do remote restore outside of the root
account. You may substitute "operator" with any other group that contains
the users you want to use restore. The group "operator" is a default group
on SunOS 4.x. With this method, restore still is still setuid and vulnerable,
but you will have an accountable group of users who can use restore. The
4550 makes restore readable and executable by root and the group you specified,
and unreadable by everyone else. Thus, this solution does not totally disable
the remote restore capability, but allows designated user groups to have
this capability.
In addition, as a security prevention measurement, we suggest that you restrict
the accessability of dump. The "dump" utility, the partner of restore, is
frequently used to do backups on a system. Restore is used to extract the
files that dump has stored on tape. CIAC's recommendation is to make dump
unreadable, non-executable and unwriteable to everyone by using the following
workaround:
chmod 6750 /usr/etc/dump
This will restrict access of dump by allowing its use only by root and the
group to which dump belongs (eg. operator, staff, or wheel).
For further information, contact:
Ana Maria de Alvare'
Computer Incident Advisory Capability
Lawrence Livermore National Laboratory
P.O. Box 808, L-303
Livermore, CA 94550
(415) 422-7007 or (FTS) 532-7007
anamaria@lll-lcc.llnl.gov
________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
ADVISORY NOTICE
________________________________________________________________
The nVIR virus has recently infected significant numbers of Macintosh
systems at several DOE sites. There are different strains of this virus. Each
strain causes somewhat different symptoms such as printing errors on laser
printers, slow system response time, or unpredictable system crashes.
The exact mechanisms by which nVIR spreads have recently been determined.
Removable media (e.g., disks) are the primary means by which nVIR spreads.
Thus, if a disk used in an infected Macintosh is removed and inserted in a
second Macintosh, the other machine will become infected if any application on
that disk is executed in the second machine. In addition, any method used to
transfer programs between Macintoshes will spread the nVIR virus. This
includes transfer via shareware over a network. However, nVIR cannot spread
via a print network's hardware.
nVIR is initially difficult to detect. It spreads quickly and frequently
affects backups before eradication procedures can be initiated.
Disks brought in from off-site are the most common source of nVIR infections.
Unauthorized copies of commercial software brought from off-site or exchanged
within a site also present a substantial risk of nVIR infection. Vendor
demonstration programs are another suspected source of the nVIR virus.
We urge you first of all to review your site's policy on sharing disks and
using and distributing non-licensed software. Another essential damage
prevention measure is to have good anti-viral software available at your site.
CIAC recommends that you test any suspect disk with Disinfectant 1.2, a
freeware package which also eradicates viruses. Virus Detective, a
shareware package, also tests disks to see if they are clean of nVIR and
several other viruses. Although it is tedious to use, Gatekeeper, another
shareware program, will provide several protection mechanisms. It is
important to educate users about the importance of using only software
from trusted sources to reduce the possibility of virus infections. Finally,
CIAC recommends that your site uses dedicated machines for on-site vendor
demonstrations.
For further information or to obtain copies of Disinfectant, Virus Detective
and/or Gatekeeper, contact CIAC at (415) 422-8193 or (FTS) 532-8193. CIAC's
e-mail address is:
CIAC@tiger.llnl.gov
________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
INFORMATION BULLETIN
________________________________________________________________
CIAC
Computer Incident Advisory Capability
Information Bulletin
September 22, 1989
Information about Columbus Day (Datacrime) Virus Affecting IBM PCs and
PC Compatibles
I. Executive Summary
On September 8, 1989 the DOE Computer Incident Advisory Capability
(CIAC) issued a notice about the Columbus Day Virus, also known as the
DATACRIME virus, which may attack MS-DOS (PC-DOS) personal computers.
Since that time CIAC has gathered considerable information1 and has
obtained and analyzed two versions of this virus.
The Columbus Day family of viruses will infect applications on IBM
Personal Computers (PCs) and Compatibles. Execution of an infected
program will cause the virus to replicate to other applications. When
the system date is between October 13th and December 31st of any year
and the computer has a hard disk, the virus strikes and displays the
message:
DATACRIME VIRUS
RELEASED: 1 March 1989
Simultaneously, the virus makes the hard disk unreadable. Recovery
after the virus has altered the disk is extremely difficult. The
enclosed procedures will help to assure non-interrupted use of
affected computers.
This memo contains recommendations that users of an IBM personal
computer or compatible computers (PC) may follow to prevent loss of
information due to this virus. Also included are technical procedures
on how to detect, protect, eradicate and recover from the Columbus Day
family of viruses. A survey form is provided to aid the CIAC team in
collecting data concerning the spread of this virus. It is requested
that this form be completed at each site and returned to CIAC as soon
as possible.
II. Detailed Information on the Columbus Day (DATACRIME) Virus
DATACRIME-V1(also known as the 1168 Virus, named for its length) and
DATACRIME-V2 (also known as the 1280 virus) are both closely related
Columbus Day Viruses with only minor changes. A related virus,
DATACRIME II, is currently being examined. This bulletin gives
details about what to expect from this family of viruses and makes
further recommendations for protecting your systems.
You may have seen a report about this topic on CNN or read about it in
your local newspaper. However, all indications at this time are that
these viruses are not as widespread as other viruses affecting IBM PCs
and PC compatibles. The Computer Virus Industry Association(CVIA)
reports that infections have been minimal. This data is collected
from reports by programs like VIRUSCAN, and represents a very large
sampling of the community. However, as with all viruses we should be
prepared. If the DATACRIME virus attacks your machine it could do
serious damage. Good backups are essential.
The DATACRIME (V1 and V2) family of viruses will infect one .COM file
each time an infected program is executed. DATACRIME II will infect
both .COM and .EXE files. It does this by searching the current
directory and all sub-directories on the "C:" drive for a file
to infect. If it fails to find a file, it will search other drives on
your machine for a candidate file. The virus will not infect any file
with "D" as the seventh letter of its name; thus, COMMAND.COM
will not be infected. Each time the virus is run it checks the
current date. If the date is between October 13th and December 31st
of any year and the computer has a hard disk it displays the message:
DATACRIME VIRUS
RELEASED: 1 March 1989
Simultaneously, the virus formats the first 8 tracks of cylinder 0 of
the hard disk. This will effectively destroy the partition table,
master boot track, the boot record, the File Allocation Table (FAT),
and a portion of the root directory. Recovery at this point will be
very difficult and will require a low level format1. Due to the way
the virus executes, it's behaviors range from no action, to
complete data loss of the hard disk. We stated in the previous memo
on the Columbus Day Virus that you may be able to do a partial
recovery with, for example, Disk Doctor, in Norton Utilities Version
4.5. As we examined the virus we determined that there is only a very
small chance of recovery by this method. Prevention and backups are
the best course.
The CIAC recommends that each PC user follow the procedures below:
First Backup your hard-disk - most importantly the data. These
viruses can't propagate through data files and you can always
restore your applications from the distribution disks, but if your
data is important to you, you should back it up now.
Now that you've backed up your data you can try to detect the
virus. Utilities that search files for particular ASCII strings are
ineffective, since the ASCII strings in the virus code are encrypted.
There are several methods you can use to detect this virus. The first
method, while labor intensive, doesn't require any special
software. Check for any increase in the size of your .COM or .EXE
files. The virus will not infect COMMAND.COM so examine other
executable files, for example, FORMAT.COM, CHKDSK.COM, FIND.EXE and
PRINT.COM.
Note that there are other reasons why the file size may not match.
For example, you may have updated to a newer version of a program, or
you are running Data Physician which changes the size of the file.
However, a size change should signal that you need to investigate
further.
Another possible method is to use a commercial product that will
detect these viruses. This includes products like Flu-Shot+,
VIRUSCAN, or Data Physician, which should report the existence of
these viruses as well as certain other viruses.
If you find you are infected but DATACRIME hasn't struck yet
DON'T PANIC. Do the following: Copy the infected files to a
diskette and clearly label it as a virus and protect this disk. We
need copies of all DATACRIME viruses that infect DOE machines so
please call the CIAC for instructions on how to handle this sample.
You must completely rid your machine of this virus. The procedure
below is believed to be necessary because current eradication programs
can not guarantee 100% recovery.
Again, make sure that you have backed up all your data. Ensure that
there are no system or application files (any file that ends in .COM
or .EXE) on your backup floppies. The next step will destroy all
information on the hard disk, so ensure that your backups and
distribution disks are safe. Follow the necessary procedures to
format your hard-drive. Seek expert assistance if you are not
familiar with how to carry out this procedure.
Now take out your original disks and write protect each one of them.
If you have a virus detection program that works, run it on the
application disks to ensure they are virus-free. Reinstall all of
your applications from the original virus-free distribution disks.
You should examine all of your floppies and backups that contain
applications or system files to prevent reinfection. Remember, one
infected file will reinfect your system.
The CIAC would like to survey all DOE sites for the Columbus Day
Viruses. We request that sites do random checks of your IBM PCs and
compatibles and report back by phone, fax or email using the enclosed
form. Should you find a virus, label your diskettes with the word
VIRUS and mail to:
CIAC, David S. Brown, L-542
P.O. Box 808
7000 East Ave.
Lawrence Livermore National Laboratory
Livermore, CA 94550
We want to prevent virsuses from becoming widespread. For questions
or for further information, please contact the CIAC staff:
CIAC
(415) 422-8193 or FTS 532-8193 ciac@tiger.llnl.gov
CIAC FAX
(415) 423-0913
David Brown
(415) 423-9878 or FTS 543-9878 brown@pantera.llnl.gov
Tom Longstaff
(415) 423-4416 or FTS 543-4416 longstaf@pantera.llnl.gov
Ana Maria De Alvare'
(415) 422-7007 or FTS 532-7007 anamaria@pantera.llnl.gov
Gene Schultz, Leader
(415) 422-8193 or FTS 532-8193 gschultz@pantera.llnl.gov
The CIAC would like to survey all DOE sites for the Columbus
Day/DATACRIME virus. We request that sites do random checks of their
PCs and report back by fax or email with the following information
whether or not a virus infection was detected:
Name _______________________________________ Phone____________________
Organization ____________________________________________________________
Address _________________________________________________________________
_________________________________________________________________________
Number of PCs tested ________________
Number of PCs infected by the DATACRIME virus ________________
Number of PCs infected by other viruses ______________________
Method(s) of Detection _______________________________________
Comments __________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
Please send your survey results and any infected disks to:
CIAC
(415) 422-8193 or FTS 532-8193 ciac@tiger.llnl.gov
CIAC FAX
(415) 423-0913
David Brown
(415) 423-9878 or FTS 543-9878 brown@pantera.llnl.gov
Tom Longstaff
(415) 423-4416 or FTS 543-4416 longstaf@pantera.llnl.gov
Ana Maria De Alvare'
(415) 422-7007 or FTS 532-7007 anamaria@pantera.llnl.gov
Gene Schultz, Leader
(415) 422-8193 or FTS 532-8193 gschultz@pantera.llnl.gov
________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
ADVISORY NOTICE
________________________________________________________________
NOTICE OF TROJAN HORSE PROGRAM AFFECTING COMPUTERS ON THE
INTERNET USING TELNET
The DOE Computer Incident Advisory Capability (CIAC) has learned of the
presence of a trojan horse program spreading over the Internet. This program
has caused unauthorized system activity on several computers that run Telnet.
The bogus Telnet program logs outgoing login sessions (including user names and
passwords). This problem could extend to any version of Telnet for which an
attacker has the source code. Currently, only UNIX systems have been affected,
though any system to which an attacker can gain access could be affected in the
future.
Historically, attackers have logged pertinent information to directory names
such as "..." and ".mail". To determine if your Telnet program has been
affected, however, you could use a search command (e.g., "strings" command for
UNIX) on these directory name strings. However, attackers may not elect to use
the same directory name strings in the future, since an attacker can change the
logging directory when compiling the trojan horse program. Therefore, CIAC
recommends that you periodically use one of the following methods to determine
if the trojan horse has replaced your Telnet program:
1) Compare the size of an original Telnet file to the installed version.
A difference in size would indicate the installed version has been modified and
should be checked.
2) Compare the original Telnet source code and the version installed on
your particular system using a comparison program (e.g., DIFF, SUM or CMP) to
identify modifications to the installed version.
3) Use the command:
strings `which telnet` |grep / | grep -v \@\(\#\) | grep -v on/off
You will obtain all of the absolute pathnames (i.e., filenames that have an
explicit directory component) that were not specifically constructed to
protect against comparison tests. Normally these filenames are:
/etc/services
/etc/hosts
(Note: this test is a "quick and dirty" way of testing for the trojan
horse program. It eliminates the need to load a "clean copy" from tape
to perform more extensive but more thorough comparison tests.)
If you discover you have been affected by the trojan horse program, it will
be necessary to:
1) remove any log files that had been made by the program,
2) change all passwords on all your machines, because the trojan horse
program catches passwords for breakins into other machines, and
3) reinstall a clean version of the Telnet program.
In addition, if you have been affected by this trojan horse program, you
can help CIAC reach others who have also been affected but may not yet
realize that their systems have this problem. Please inform CIAC of:
1) what files the bogus program has created, and 2) the contacts coming
into the affected machine(s). Note: you can obtain a listing of these
contacts by using the UNIX 'last' command. If you have been affected or if
you need further information, please contact Gene Schultz, CIAC Manager, at
(415) 422-8193 or (FTS) 532-8193 or send e-mail to:
gschultz%nsspa@icdc.llnl.gov.
or
ciac@tiger.llnl.gov
.po 1.2i
.ls 1
.nh
.fo ''-%-'89/06/09'
.ce
\fBNOTICE OF AVAILABILITY OF SUN PATCH FOR RCP AND RDIST\fR
.ce
\*(td
.sp 1
.pp
Several weeks ago, the DOE Computer Incident Advisory Capability (CIAC) reported a
UNIX security problem involving rcp and rdist in 4.3BSD, 4.3BSD-tahoe,
and all versions of UNIX using BSD networking code, as well as SunOS (all
versions). Patches for BSD but not SUN systems were available at the
time you received an announcement about the rcp and rdist
vulnerabilities. However, patches for SUN3 and SUN4 systems are now
available. You may obtain these patches from several sources, to
be described shortly.
.nr ii -8n
.ip
\fBTo transfer the patches:\fR
.nr ii 4n
.np
Log in to your local SUN machine.
.np
Get into the directory into which you want the patches to be transferred.
You can accomplish this by typing: \fIcd\fR "dir", where "dir"
is the name of the directory to which you want to copy the patches.
.np
Use one of the following options:
.nr ii -8n
.ip
\fBOPTION I- Transfer the Patches from uunet.uu.net\fR
.nr 4n
.nr ii .5i
.ip (a)
\fBType: \fIftp uunet.uu.net \fR <RETURN>
.ip
The remote system will prompt you as follows:
.(l
Name:
\fBtype:\fI anonymous\fR <RETURN>
Passwd:
\fBtype:\fI guest\fR <RETURN>
ftp>
.)l
.nr ii .5i
.ip (b)
When you get an "ftp>" prompt then
.(l
\fBType: \fIcd sun-fixes\fR <RETURN>
and then type: \fIls\fR <RETURN>
(this will help you see what directory you are in.)
.)l
.nr ii .5i
.ip (c)
Then \fBtype: \fItype image\fR <RETURN>
.nr ii .5i
.ip (d)
Now you are ready to copy the patches.
.(l
If you are running a SUN3 system, i.e. 68020.,
\fBType: \fIget \fRrcp.sun3.Z <RETURN>
Or for SUN4 systems, i.e. SPARC architecture.,
\fBtype: \fIget \fRrcp.sun4.Z <RETURN>
.ip
Do the same for: \fIget \fR"rdist.sun3.Z" <RETURN>
.ip
or \fIget \fR"rdist.sun4.Z" <RETURN>
.ip (e)
Finally \fBtype: \fIquit\fR <RETURN>
.sp 2
.nr ii -8n
.bp
.ip
\fBOPTION II- Transfer the patches from lll-crg.llnl.gov\fR
.sp
If you cannot connect to uunet.uu.net, then try the following:
.pp
.nr ii 4n
.ip (a)
\fBType:\fI ftp lll-crg.llnl.gov\fR <RETURN>
.ip
The remote system will prompt you as follows:
.(l
Name:
\fBtype:\fI anonymous\fR <RETURN>
Passwd:
\fBtype:\fI guest\fR <RETURN>
ftp>
.)l
.ip (b)
\fBType: \fIcd sun\fR <RETURN>
.ip (c)
\fBGet\fR the files as shown above. (Refer to I.c and I.d above)
.ip (d)
Finally \fBtype: \fIquit\fR <RETURN>
.sp
.nr ii -8n
.ip
\fBTo install the patches on your system:\fR
.ip
After you get the patches and are back to your local machine, do the following:
.ps
.nr ii 4n
.pp
.nr ii .5i
.ip (1)
\fBMake your files readable.\fR
.ip
\fBType:\fI uncompress rcp.sun3.Z.\fR <RETURN>
.ip
\fBType:\fI uncompress rdist.sun3.Z.\fR <RETURN>
.ip
the \fIrdist.sun3.Z\fR is for SUN3 systems, if you have a SUN4
it will be \fIrdist.sun4.Z\fR. The same naming rule is being
used on \fIrcp.sun3.Z\fR.
.nr ii .5i
.ip (2)
\fBReplace the original rcp and rdist.\fR
.ip
You can achieve this by:
.(l
2.1) \fBType:\fI whereis rcp\fR <RETURN>
Your computer will return a pathname such as: /usr/ucb/rcp.
Write down that pathname.
2.2) Do the same for "rdist". \fBType:\fI whereis rdist\fR <RETURN>
2.3) \fBType:\fI cp "rcp-pathname" "rcp-pathname.orig"\fR <RETURN>
(where "rcp-pathname" is the pathname from step 2.1 above.)
\fBType:\fI cp "rdist-pathname" "rdist-pathname.orig"\fR <RETURN>
(where "rdist-pathname" is the pathname from step 2.2 above.)
\fBType:\fI cp rcp.sun3 "rcp-pathname" <RETURN>
\fBType:\fI cp rdist.sun3 "rcp-pathname"\fR <RETURN>
.)l
.pp
You can now test these utilities.
If you cannot connect to either uunet.uu.net or lll-crg.llnl.gov via the network
or need further assistance,
please contact:
.(l
Ana Maria De Alvare'
anamaria@lll-lcc.llnl.gov
(415) 422-7007 or (FTS) 532-7007
or send e-mail to:
ciac@tiger.llnl.gov
.)l
________________________________________________________________
THE COMPUTER INCIDENT ADVISORY CAPABILITY
CIAC
ADVISORY NOTICE
________________________________________________________________
NOTICE OF VULNERABILITY AFFECTING MACINTOSH
AND IBM PC'S RUNNING NCSA TELNET
The DOE Computer Incident Advisory Capability (CIAC) has learned of a serious
vulnerability in Telnet software made by NCSA that runs on both Macintosh and
IBM PCs. This vulnerability enables anyone on a system that has network access
to a Macintosh or IBM PC running NCSA Telnet to access that particular type of
computer without a password, and copy, change, or delete files on it. Please
note that the potential exists for any node on the network (i.e. the world) to
have this accessibility. Access to the Macintosh or IBM PC is via FTP on the
host. The Macintosh or IBM PC will then execute FTP commands if NCSA Telnet is
running on it, even if NCSA Telnet is running in the background (e.g., under
MultiFinder on the Macintosh). Once access is gained, files can be copied to
or from the Macintosh or IBM PC.
Whether Macintosh or IBM PCs at your site have this vulnerability depends on
how NCSA Telnet was installed. Your systems are vulnerable if you are missing
the line:
passfile="filename"
in your config.tel file. The line "ftp=no" can be used to disable ftp.
Even if this line is included, however, your system could still be vulnerable,
since this command is easily overridden while NCSA Telnet is running by
selecting "FTP Enable" in the File menu.
NCSA Telnet is delivered with the 'passfile="filename"' line commented out of
the config.tel file using the # sign as:
#passfile="filename".
When the passfile line is omitted or commented out, FTP transfers are enabled
without requiring the use of passwords. If the Macintosh or IBM PCs at your
site are subject to this vulnerability, CIAC recommends that you ensure the
passfile="filename" line is included in the configuration file, where
"filename" (quotes required) can either specify a dummy file name or a valid
password file. You should use a dummy file name when NCSA Telnet is not being
used to assure that users do not enable NCSA Telnet without first making a
password file. Using a dummy file name will turn on password checking which
effectively disables FTP. However, if you plan to use NCSA Telnet, you should:
1) make an encrypted password file using Telpass, and
2) use a complete pathname specification for the file name
(e.g., \etc\passwd).
By including the passfile line in config.tel, someone who wants to use FTP must
either delete the passfile line in the config.tel file or create a password
file.
For further information, please contact Gene Schultz, CIAC Manager, at
(415) 422-8193 or (FTS) 532-8193, or send e-mail to:
gschultz%nsspa@icdc.llnl.gov