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 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 X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include X#include "pathnames.h" X X#ifdef KERBEROS X#include 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 "); 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 .ip The remote system will prompt you as follows: .(l Name: \fBtype:\fI anonymous\fR Passwd: \fBtype:\fI guest\fR ftp> .)l .nr ii .5i .ip (b) When you get an "ftp>" prompt then .(l \fBType: \fIcd sun-fixes\fR and then type: \fIls\fR (this will help you see what directory you are in.) .)l .nr ii .5i .ip (c) Then \fBtype: \fItype image\fR .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 Or for SUN4 systems, i.e. SPARC architecture., \fBtype: \fIget \fRrcp.sun4.Z .ip Do the same for: \fIget \fR"rdist.sun3.Z" .ip or \fIget \fR"rdist.sun4.Z" .ip (e) Finally \fBtype: \fIquit\fR .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 .ip The remote system will prompt you as follows: .(l Name: \fBtype:\fI anonymous\fR Passwd: \fBtype:\fI guest\fR ftp> .)l .ip (b) \fBType: \fIcd sun\fR .ip (c) \fBGet\fR the files as shown above. (Refer to I.c and I.d above) .ip (d) Finally \fBtype: \fIquit\fR .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 .ip \fBType:\fI uncompress rdist.sun3.Z.\fR .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 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 2.3) \fBType:\fI cp "rcp-pathname" "rcp-pathname.orig"\fR (where "rcp-pathname" is the pathname from step 2.1 above.) \fBType:\fI cp "rdist-pathname" "rdist-pathname.orig"\fR (where "rdist-pathname" is the pathname from step 2.2 above.) \fBType:\fI cp rcp.sun3 "rcp-pathname" \fBType:\fI cp rdist.sun3 "rcp-pathname"\fR .)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