CIAC documents FY 1992 Series C ciacfy92.txt All public FY92 CIAC bulletins. c-01.txt ciac-tftpd-patch-for-rs6000 c-02.txt ciac-dir-II-virus-on-msdos c-04.txt ciac-rdist-vulnerability-on-unix c-05.txt ciac-vms-sysman-trojan-preliminary c-06.txt ciac-sunos-fsirand-nfs-problem c-07.txt ciac-vms-sysman-trojan-additional c-08.txt ciac-sunrdist c-10.txt ciac-openwindows-v3 c-11.txt ciac-virus-in-network-support-encyclopedia c-12.txt ciac-hp-apollo-crp-vulnerability c-13.txt ciac-NeXTstep-NetInfo c-15.txt ciac-michelangelo-virus c-16.txt ciac-net-internet-intrusions c-17.txt ciac-new-macintosh-virus-mbdf c-18.txt ciac-att-rexecd c-19.txt ciac-VMS-SAS-v5.18 c-20.txt ciac-sgi-pseudo-tty c-21.txt ciac-aix-rexd c-25.txt ciac-sunos-nis-patch c-26.txt ciac-sunos-environment-variable c-27.txt ciac-PKZIP-virus-alert c-28.txt ciac-sunos-security-patches c-29.txt ciac-sunos-patch-summary c-30.txt ciac-vms-monitor _____________________________________________________ The Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ INFORMATION BULLETIN New TFTPD server available for IBM RS6000 systems October 7, 1991, 1400 PDT Number C-1 ----------------------------------------------------------------------------- PROBLEM: All world readable files can be remotely retrieved using TFTP on IBM RS6000 systems running AIX. PLATFORM: IBM RS6000 systems running versions of AIX prior to the 2009 update. DAMAGE: Potential unauthorized access and disclosure of critical system files. SOLUTIONS: Request and install TFTPD patch APAR number ix22628 from IBM; this patch limits the access of TFTP to specified directories. ----------------------------------------------------------------------------- Critical Facts about the new TFTPD server CIAC has learned of a version of TFTPD available for IBM RS6000 systems running AIX. This version will eliminate a problem in current versions of TFTPD that allows potential unauthorized access and disclosure of world-readable (including critical system) files by adding a feature that denies access to sensitive areas of the system. This program continues to support tftp access (which is required to support X-Terminals). This new TFTPD server uses a configuration file (/etc/tftpaccess.ctl) to allow or deny access to specific directories and sub-directories before permitting any transfer of data. During TFTP access the file /etc/tftpaccess.ctl is searched for lines that start with "allow:" or "deny:" All other lines are ignored. If the file does not exist, the access is allowed in the currently supported fashion. For example, the /usr directory might be allowed and the /usr/ucb directory might be denied. This means that any directory or file in the /usr directory except the /usr/ucb directory can be accessed. The entries in the /etc/tftpaccess.ctl file must be absolute path names. The permissions on the /etc/tftpaccess.ctl file should be writable only by the root user (mode 0644). IBM RS6000 customers may request this implementation of TFTPD by calling IBM Service and requesting APAR number ix22628. This version of TFTPD will appear in the 2009 update and the next release of AIX. To install this new version of TFTPD, replace your current version of /etc/tftpd with the patched program and follow the provided instructions for setting up a /etc/tftpaccess.ctl file with the appropriate "allow:" or "deny:" lines. Please contact IBM or CIAC for assistance. Tom Longstaff (510) 423-4416**/(FTS) 543-4416 longstaf@llnl.gov Send e-mail to ciac@llnl.gov or call CIAC at (510) 422-8193**/(FTS) 532-8193. FAX messages to: (510) 423-8002**/(FTS) 543-8002. Previous CIAC bulletins and other information is available via anonymous ftp from irbis.llnl.gov (ip address 128.115.19.60). **Note area code has changed from 415, although the 415 area code will work until Jan. 1992. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the University of California, and shall not be used for advertising or product endorsement purposes. _____________________________________________________ The Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ Information Bulletin Dir II Virus on MS DOS Computers October 18, 1991, 15:30 PDT Number C-2 Critical Dir II Virus Facts _________________________________________________________________________ Name: Dir II virus Aliases: Dir-2, MG series II, Creeping Death, DRIVER-1024, Cluster Virus Type: Directory infector with stealth characteristics Variants: Unsubstantiated reports exist for two variants Platform: MS-DOS computers Damage: May destroy all .EXE and .COM files and backup diskettes, crash some lookalike systems, CHKDSK /F destroys all executible files Symptoms: CHKDSK reports many cross-linked files and lost file chains can corrupt backups, copied files are only 1024 bytes long, more (see below) First Discovered: May 1991 in Bulgaria Eradication: Perform a series of simple DOS commands (see below) _________________________________________________________________________ The Dir II virus presents a new type of MS-DOS virus called a directory infector. This virus modifies entries in the directory structure, causing the computer to jump to the virus code before execution of a program begins. Also, this virus utilizes stealth techniques to hide its existence in memory. How Infection Occurs Initial hard disk infection occurs when a file with an infected directory is executed. The virus establishes itself in memory and puts a copy of itself on the last cluster of the disk. Once the virus is active in memory, executing any file (infected or not) will cause the virus to infect the directory entry of ALL .EXE and .COM files in the current directory and in the directories listed in the PATH variable. Additional detailed information on the infection technique is included in the appendix at the end of this bulletin. Potential Damage If there is currently information residing on the last cluster of the disk, this virus will overwrite it upon installation. Since most backup utilities fill diskettes to capacity, backups are prone to immediate corruption upon initial infection. The most damaging characteristic of this virus occurs if a user boots >from a clean diskette and attempts to run a disk optimizer program such as CHKDSK /F, Norton Disk Doctor, or other similar utility programs. When such a program attempts to "fix" the disk, all infected executibles will "become" the virus, effectively destroying the original file! Detection Although current versions of many common anti-viral utilities will not detect this virus and are unable to remove it, manual detection can be performed using the following methods: 1. Boot from the suspect infected hard disk. With the suspected virus active in memory, execute the command CHKDSK with NO arguments. Then reboot from a clean, write protected diskette (such as the original DOS diskette), and execute the command CHKDSK with no arguments again. If many cross-linked files and lost file chains are reported during the second CHKDSK and not the first, it is an indication of infection. 2. Boot from the suspected infected hard disk. With the suspected virus active in memory, use the COPY command to copy suspect files with the extension .EXE or .COM. Examine the file length of these copied files by using the DIR command, then reboot from a clean, write protected diskette and perform the same copy command(s). If the file length of the second copy is very small (around 1K) but the file length of the first copy is much larger, you may be infected with the Dir II virus. Eradication To manually eradicate this virus, follow these steps for every infected disk and diskette: 1. While Dir II is active in memory, use the COPY command to copy all .EXE and .COM files to files with a different extension. Example: COPY filename.com filename.vom 2. Reboot system from a clean, write protected diskette to ensure the system does not have the virus in memory. 3. Delete all files with extensions of .EXE and .COM. This will remove all pointers to the virus. 4. Rename all executibles to their original names. Example: RENAME filename.vom filename.com 5. Examine all these executibles you have just restored. If any are 1K in length, they probably are a copy of the virus. Destroy any executibles of this size. For additional information or assistance, please contact CIAC: Karyn Pichnarczyk (510) 422-1779 **or (FTS) 532-1779 karyn@cheetah.llnl.gov Send e-mail to ciac@llnl.gov or call CIAC at (510) 422-8193**/(FTS)532-8193. **Note area code has changed from 415, although the 415 area code will work until Jan. 1992. CIAC would like to thank Bill Kenny of DDI for his help with this bulletin. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the University of California, and shall not be used for advertising or product endorsement purposes. Appendix: Detailed DIR II Information The DOS directory structure contains the following entries: filename, extension, attribute, time, date, cluster, filesize, and an unused area; the cluster entry is the pointer to where the actual file exists on the disk. Dir II infects the directory structure by scrambling the original cluster entry and storing it in part of the unused area, then placing a pointer to the viral code in the cluster entry. Thus when a program is executed, the computer executes the viral code, the virus decrypts the original cluster entry, then the virus allows the original program to proceed. Upon initial infection, the virus links itself into the device driver chain, copying itself to the last cluster (or last two clusters, if cluster size is less than 1024 bytes) on the disk and infects the directory structure of all .EXE and .COM files residing in the current directory and all directories defined in the path. The virus infects all files with .EXE or .COM as an extension whether or not they are executible, EXCEPT if the size of the file is less than 2K, larger than 256K, or has an attribute of System, Volume, or Directory set. Therefore it does not infect the two hidden system files, but it DOES infect command.com. Following the supplied eradication steps will simply remove all "live" pointers to the viral code. After eradication you may wish to use a direct disk access utility (such as Norton Utilities) to directly access the viral code existing on the last cluster on the disk and overwrite it with blanks. Another recommended final clean-up entails running a disk optimizer program that will clean out all unnecessary deleted files. It is important to remember that this virus has infected all .COM and .EXE files, even if they are tagged as deleted. Therefore if an undelete utility is used on these files, the virus can resurface. Other Facts About Dir II - Using CHKDSK to detect this virus from a clean boot will only work if there is more than one infected executible on a disk. - Dir II does not infect partitions that are accessed through a loadable device driver. - Due to the stealth characteristics of Dir II, while the virus is memory-resident all file accesses, backups, deletes, copies, etc are accomplished with no discernable problems. Also, errors resulting from execution of Dir II (such as an attempt to infect a write-protected diskette) are suppressed by the virus. - The first execution of a file causes the virus to become memory resident. Before it is resident, if a file is copied from an infected disk to an uninfected disk all that will copy will be a 1K length file containing the virus. After eradication procedures this copied file will still be a copy of the virus. Such files can be a very good clue to track where the virus originated. - If the virus is not active in memory, interaction with infected files produces unusual results. Copying an infected file will copy a file only 1K long (the virus itself). Deleting a file will mark it as deleted, not but does not affect the virus. - With the virus active in memory, formatting a disk will produce the virus in the last cluster. - Because this virus uses a new type of attack scheme, versions of most anti-viral utilities prior to October, 1991 utilities will not detect it, and cannot clean it. Since Dir II associates itself with the device drivers, programs which detect unauthorized requests to become memory resident do not detect this virus. - This virus is not compatible with all non IBM MS-DOS machine ROMS and will crash some hard disk systems immediately upon initial infection. _____________________________________________________ The Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ INFORMATION BULLETIN Vulnerability in the rdist utility on UNIX platforms October 23, 1991, 1000 PDT Number C-4 ----------------------------------------------------------------------------- PROBLEM: Bug in /usr/ucb/rdist may allow unauthorized file changes PLATFORM: All UNIX platforms supporting the rdist utility (See Below) DAMAGE: Could be exploited to create setuid files SOLUTIONS: Apply patch supplied by the vendor (see list below) or disallow access by non-privledged users until a patch is available ----------------------------------------------------------------------------- Critical Facts about the rdist vulnerability CIAC has learned of a vulnerability associated with the Berkeley Software Distribution (BSD) rdist utility. This program can commonly be found at /usr/ucb/rdist; however, the location may vary depending on the vendor and system configuration. This vulnerability may allow unauthorized system modification by non-privileged users. This vulnerability appears to be in all versions of rdist shipped by vendors supporting this utility to date. VENDORS THAT DO NOT SHIP /usr/ucb/rdist (Note: Even though these vendors do not ship rdist, it may have been added later (for example, by the system administrator). It is also possible that vendors porting one of these operating systems may have added rdist. In both cases corrective action must be taken.) Amdahl AT&T System V Data General The following list of vendors will supply a patched version of rdist to replace the vulnerable version. Cray Research, Inc. UNICOS 6.0/6.E/6.1 Field Alert #132 SPR 47600 For further information contact the Support Center at 1-800-950-CRAY or 612-683-5600 or e-mail support@crayamid.cray.com. NeXT Computer, Inc. NeXTstep Release 2.x A new version of rdist may be obtained from your authorized NeXT Support Center. If you are an authorized support center, please contact NeXT through your normal channels. NeXT also plans to make this new version of rdist available on the public NeXT FTP archives. Silicon Graphics IRIX 3.3/4.0/4.0.1 Patches may be obtained via anonymous ftp from sgi.com in the sgi/rdist directory. Sun Microsystems, Inc. SunOS 4.0.3/4.1/4.1.1 Patch ID 100383-02 Patches may be obtained via anonymous ftp from ftp.uu.net or from local Sun Answer Centers worldwide. If there is no patch available yet for your system, CIAC recommends that you modify the execute permission of the rdist utility so that unprivledged users cannot execute it. To do this, locate the rdist file (usually located in /usr/ucb/rdist) and execute the following as root: chmod 711 /usr/ucb/rdist The impact of this workaround is that non-privledged users and programs will not be able to execute the rdist utility as root. Please contact CIAC for assistance. David Brown (510) 423-9878**/(FTS) 543-9878 dsbrown@llnl.gov Send e-mail to ciac@llnl.gov or call CIAC at (510) 422-8193**/(FTS) 532-8193. FAX messages to: (510) 423-8002**/(FTS) 543-8002. Previous CIAC bulletins and other information is available via anonymous ftp from irbis.llnl.gov (ip address 128.115.19.60). **Note area code has changed from 415, although the 415 area code will work until Jan. 1992. CIAC would like to thank Barbara Fraser of the Computer Emergency Response Team/Coordination Center for some of the information provided in this bulletin. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the University of California, and shall not be used for advertising or product endorsement purposes. _____________________________________________________ The Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ Information Bulletin Preliminary Information about SYSMAN.EXE Trojan Horse November 8, 1991, 16:00 PDT Number C-5 Critical Facts about SYSMAN.EXE Trojan Horse _________________________________________________________________________ PROBLEM: A trojan horse program installed in several systems PLATFORM: VMS systems connected to DECnet. DAMAGE: Allows potential unauthorized privileged access; unauthorized changes to critical system files. SOLUTIONS: Scan SYS$LIBRARY for executable called OBJ.EXE or check for modification of length of SYSMAN.EXE file; if OBJ.EXE or bogus SYSMAN.EXE program is found, replace with copy from original distribution tape, then delete OBJ.EXE _________________________________________________________________________ CIAC has been informed of a trojan horse program found in several VMS systems connected to the DECnet. All affected systems identified to date are systems connected to the European DECnet; no systems in the DOE community or U.S.A. are known to be infected by this bogus program at this time . At this moment we have disassembled approximately 98 percent of the binary code, and are distributing this bulletin to provide an interim progress report. Although early information provided to CIAC initially suggested that this program was a worm, we have been unable to locate any self-proliferation routines in this program. It is likely that the author of this trojan horse planted this program either by breaching a privileged account or by breaching an unprivileged account and escalating privilege. The intruder renames the SYS$SYSTEM:SYSMAN.EXE image to SYS$LIBRARY:OBJ.EXE. When the trojan horse program is installed, the intruder replaces the SYSMAN.EXE image with the trojan horse program. The SYSMAN.EXE trojan horse enables an intruder to grant privilege to an unprivileged account, thereby allowing that intruder back door access to system privilege. To detect the trojan horse program, run the SYSMAN program. After exiting, type the command SHOW SYMBOL * If the result contains a definition for the symbol OBFJ defined as "$SYS$LIBRARY:OBJ.EXE" or if you find the file SYS$LIBRARY: OBJ.EXE on your system, it is extremely likely that your system contains this trojan horse. CIAC recommends that if your system contracts the SYSMAN.EXE trojan horse, you should save the corrupted SYSMAN image. We request that you send a copy of this image to CIAC, and recommend that you replace it using the original distribution media. For additional information or assistance, please contact CIAC: Hal Brand Karyn Pichnarczyk (510)422-0039** or or (510) 422-1779** or (FTS) 532-0039 (FTS) 532-1779 brand@addvax.llnl.gov karyn@cheetah.llnl.gov Send e-mail to ciac@llnl.gov or call CIAC at (510) 422-8193**/(FTS)532-8193. **Note area code has changed from 415, although the 415 area code will work until Jan. 1992. CIAC would like to thank the Computer Emergency Response Team/Coordination Center and DEC for assistance in handling this incident. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the University of California, and shall not be used for advertising or product endorsement purposes. _____________________________________________________ Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ Information Bulletin Security Problem in SunOS fsirand Program November 12, 1991, 1100 PDT Number C-6 _________________________________________________________________________ PROBLEM: fsirand (random number generator) program could potentially allow the guessing of NFS file handles PLATFORM: SunOS 4.1.1 systems using NFS to export file systems. DAMAGE: Allows potential unauthorized access to published file systems SOLUTIONS: Apply patches as described below _________________________________________________________________________ Critical Facts about Problem with SunOS fsirand Program Sun Microsystems has recently released a bulletin describing a security problem (Sun Bug ID 1063470) in the fsirand (random number generator) program in SunOS 4.1.1. This problem allows a potential intruder to guess NFS file handles, which could result in unauthorized access to published NFS file systems. Sun Microsystems has developed a patched version of fsirand (Sun Patch ID 100424-01) that provides greater randomness to the random number generator's seed. Sun's bulletin also provides the following information: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This patch should only be applied in conjunction with the latest version of the NFS jumbo patch, currently 100173-07 for SunOS 4.1.1. The NFS jumbo patch must be applied before the fsirand patch. NFS jumbo and fsirand patches are being developed and tested for SunOS 4.0.3 and 4.1. An announcement will be made when these patches are available. In order to maintain a level of minimum security requirements on your Sun gateway systems, please note the suggestions that follow. Users may also wish to follow the advice given below for their other file servers that may be connected to potentially untrusted machines over a network. Sun recommends that you upgrade your version of SunOS to the most recent available (currently SunOS 4.1.1), since many improvements to the security of your system have been integrated into the most recent base operating system. In addition, you should install all security related patches applicable to your current version of SunOS. Sun suggests that you apply this patch and the NFS jumbo patch to your server if it is a gateway machine or if it exports critical file systems and is accessible across a potentially untrusted network (e.g. the Internet). Please refer to the README of patch 100424-01 for additional details. The fsirand fixes have been incorporated into SYS_V Rel 4. After applying this patch, /usr/etc/fsirand (see man page fsirand(8)) should be run on all potentially exportable partitions. Follow this with a system reboot to complete the installation of random inode generation numbers. Gateway machines should also apply Patch-ID# 100296-02, which fixes the mountd problem that allows an unprivileged client to take advantage of character strings in /etc/hosts and /etc/netgroup that are equal to or greater than 256. It is also strongly advised that /etc/exports (exports(5)) files on servers be examined and modified, if necessary, to permit only the level of file sharing that is necessary. The exports(5) file allows an administrator to limit the access (and type of access) of exported directories to specific client machines. For example, a directory can be exported read-only and root access can be granted to a specified set of clients only. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - If you obtain the patch from uunet (as described above), use the following command to verify the downloaded patch from uunet.uu.net: > sum 100424-01.tar.Z The result should be: 63070 50 If you do not obtain the above result after entering the sum command, contact Sun or CIAC to obtain new checksum values. For additional information or assistance, please contact CIAC: Tom Longstaff (510) 423-4416** or (FTS) 543-4416 longstaf@llnl.gov Send e-mail to ciac@llnl.gov or call CIAC at (510) 422-8193** or (FTS) 532-8193. **Note area code has changed from 415, although the 415 area code will work until Jan. 1992. Sun Microsystems provided some of the information contained in this bulletin. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the University of California, and shall not be used for advertising or product endorsement purposes. _____________________________________________________ The Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ Information Bulletin Additional Information about the SYSMAN.EXE Trojan Horse November 15, 1991, 1530 PDT Number C-7 _________________________________________________________________________ PROBLEM: A trojan horse program disguised as SYSMAN.EXE PLATFORM: VMS systems DAMAGE: Allows non-privileged users to gain full privileges; unauthorized changes to critical system files. DIAGNOSIS: Scan SYS$LIBRARY for executable called OBJ.EXE or check for modification of length of SYSMAN.EXE file. SOLUTION: If SYSMAN.EXE trojan is found a complete re-install of VMS is recommended. _________________________________________________________________________ Critical Facts about SYSMAN.EXE Trojan Horse In Bulletin C-5 we provided information about the SYSMAN.EXE trojan horse program found in several VMS systems. We have completed analyzing this program, and now have additional information. All affected systems identified to date are systems connected to the European DECnet. To the best of our knowledge, no systems in the DOE or ESnet community have been implanted with this bogus program. In addition, we have not received any direct reports of any systems in the U.S.A. that were effected by this trojan horse program. The purpose of the SYSMAN.EXE trojan is to grant full privileges to a non-privileged account. However, this trojan will only grant full privileges when a particular key string is provided in a certain manner. It is extremely unlikely that non-privileged users not in possession of the key string nor its use could use this trojan to gain privileges. Since this trojan can only be used to escalate privileges, the intruder appears to assume that re-entry into a non-privileged account in the future is possible. The SYSMAN.EXE trojan appears to be manually planted by the intruder in two steps; the intruder renames the SYS$SYSTEM:SYSMAN.EXE image to SYS$LIBRARY:OBJ.EXE and then inserts the trojan SYSMAN.EXE into SYS$SYSTEM. Since installing this trojan requires full privileges, the intruder must have either breached a privileged account or breached a non-privileged account and escalated privileges in some manner. Signs that a VMS system has been compromised by installation of this trojan are the existance of SYS$LIBRARY:OBJ.EXE, the length of SYS$SYSTEM:SYSMAN.EXE being 166 blocks, and "$ ANALYZE/IMAGE SYS$SYSTEM:SYSMAN.EXE" showing an "image name" of "VA6" in the "Image Identification Information" section. To confirm the existence of the trojan, log into a non-privileged account, and execute the following three DCL commands: $ delete/symbol obfj Ignore the "%DCL-W-UNDSYM" error $ run sys$system:sysman Ignore the "%SYSMAN-F-NOOPER" error $ show symbol obfj If the symbol OBFJ is defined as "$SYS$LIBRARY:OBJ.EXE", the VMS system contains the SYSMAN.EXE trojan horse. If instead you get a "%DCL-W-UNDSYM" error, the SYSMAN.EXE trojan is not installed. Because installation of the SYSMAN.EXE trojan requires the intruder(s) to gain system privileges, CIAC strongly recommends that as a recovery procedure you do a complete re-install of VMS and all software installed with privilege or run under privileged accounts. This should be followed by carefully examining all security features and carefully screening all accounts, including changing the passwords of all accounts. We also request that if you find the SYSMAN.EXE trojan horse, you save the trojan SYSMAN.EXE image and send a copy of this image to CIAC for further analysis. In cases in which circumstances require the VMS system to continue running uninterrupted for a short period of time, the following sanitization procedure will remove the SYSMAN.EXE trojan: $ rename sys$system:sysman.exe sys$manager:sysman.exe-trojan $ set prot=(s:rwed,o:rwed,g,w) sys$manager:sysman.exe-trojan and finally: $ rename sys$library:obj.exe sys$system:sysman.exe or, better yet: $ delete sys$library:obj.exe;* (restore sys$system:sysman.exe from trusted distribution media) For additional information or assistance, please contact CIAC: Hal Brand (510)422-6312** or (FTS) 532-6312 (FTS) 532-6312 brand@addvax.llnl.gov Send e-mail to ciac@llnl.gov or call CIAC at (510) 422-8193**/(FTS)532-8193. **Note area code has changed from 415, although the 415 area code will work until Jan. 1992. PLEASE NOTE: Many users outside of the DOE and ESnet computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Some of the other teams include the NASA NSI response team, DARPA's CERT/CC, NAVCIRT, and the Air Force response team. Your agency's team will coordinate with CIAC. The assistance of several users in providing copies of the SYSMAN.EXE trojan horse is appreciated. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the University of California, and shall not be used for advertising or product endorsement purposes. _____________________________________________________ The Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ Information Bulletin New patch #100383-03 available for /usr/ucb/rdist on SunOS systems November 22, 1991, 1200 PST Number C-8 _________________________________________________________________________ PROBLEM: A new bug discovered in /usr/ucb/rdist may allow users to gain root privilege PLATFORM: All supported Sun architectures and operating system versions DAMAGE: Allows unauthorized root access with unrestricted access to the system SOLUTION: Apply patch 100383-03 available from Sun or ftp.uu.net _________________________________________________________________________ Critical Facts about /usr/ucb/rdist patch Sun Microsystems has recently released a security bulletin #00113 describing a new patch available for SunOS systems. This patch closes a vulnerability in the /usr/ucb/rdist program that could allow an intruder to gain root access to the system by creating a setuid root shell. This patch, and all others Sun patches are available through your local Sun answer centers worldwide as well as through anonymous ftp: in the US, ftp to ftp.uu.net and obtain the patch from the ~ftp/sun-dist directory; in Europe, ftp to mcsun.eu.net and obtain the patch from the ~ftp/sun/fixes directory. The patch must be retrieved in binary mode, then uncompressed at the local system. The checksum of compressed tarfile 100383-03.tar.Z on ftp.uu.net is 50273 163. This patch file includes new versions of the /usr/ucb/rdist program for SunOS 4.1.1, 4.1, and 4.0.3 for all supported hardware platforms. To install the patch on your system, follow the instructions available in the README file which accompanies the patch files. If you do not use the rdist command on your system, Sun recommends that you change the permissions of the /usr/ucb/rdist file using the following command (as root): chmod 0100 /usr/ucb/rdist For additional information or assistance, please contact CIAC: David Brown (510)423-9878** or (FTS) 543-9878 (FAX) (510) 423-8002** or (FTS) 543-8002 dsbrown@llnl.gov Send e-mail to ciac@llnl.gov or call CIAC at (510) 422-8193**/(FTS)532-8193. **Note area code has changed from 415, although the 415 area code will work until Jan. 1992. PLEASE NOTE: Many users outside of the DOE and ESnet computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Some of the other teams include the NASA NSI response team, DARPA's CERT/CC, NAVCIRT, and the Air Force response team. Your agency's team will coordinate with CIAC. CIAC would like to thank Ken Pon at Sun Microsystems for providing some of the information described in this bulletin. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the University of California, and shall not be used for advertising or product endorsement purposes. _____________________________________________________ The Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ Information Bulletin New patch for OpenWindows V.3 available for SunOS systems December 12 1630 PST 1991 Number C-10 _________________________________________________________________________ PROBLEM: A vulnerability in OpenWindows V.3 can be exploited to gain unauthorized root access. PLATFORM: OpenWindows, version 3 DAMAGE: Allows unauthorized root access with unrestricted access to the system SOLUTION: Apply Sun Patch ID: 100448-01 available from Sun or ftp.uu.net _________________________________________________________________________ Critical Facts about OpenWindows V.3 patch CIAC has learned from Sun Microsystems Inc. that it has a security vulnerability in its OpenWindows V 3.0 product that should be corrected immediately. CIAC advises that you replace the exploitable executable file with the patch described below. Please note that Sun only supports this product on sun4 and sun4c architectures running SunOS 4.1.1. The product is not available for sun3 architectures. The README file included with the patch has specific installation instructions that should read and understand before you attempt installation. Below is an excerpt from an alert distributed by SUN providing additional information on this patch. -------------------------------------------------------------------------- Sun Bug ID : 1076118 Sun Patch ID: 100448-01 Checksum of compressed tarfile 100448-01.tar.Z on ftp.uu.net = 04354 5 Sun advises that you replace the exploitable executable file with the appropriate replacement provided in the patch. Please refer to the patch's README file for more information. All patches listed are available through local Sun answer centers worldwide as well as through anonymous ftp: in the US, ftp to ftp.uu.net and obtain the patch from the ~ftp/sun-dist directory; in Europe, ftp to mcsun.eu.net and obtain the patch from the ~ftp/sun/fixes directory. Please refer to the BugID and PatchID when requesting patches from Sun answer centers. -------------------------------------------------------------------------- For additional information or assistance, please contact CIAC: David Brown (510)423-9878** or (FTS) 543-9878 (FAX) (510) 423-8002** or (FTS) 543-8002 dsbrown@llnl.gov Send e-mail to ciac@llnl.gov or call CIAC at (510) 422-8193**/(FTS)532-8193. **Note area code has changed from 415, although the 415 area code will work until Jan. 1992. PLEASE NOTE: Many users outside of the DOE and ESnet computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Some of the other teams include the NASA NSI response team, DARPA's CERT/CC, NAVCIRT, and the Air Force response team. Your agency's team will coordinate with CIAC. CIAC would like to thank Ken Pon at Sun Microsystems for providing some of the information described in this bulletin. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the University of California, and shall not be used for advertising or product endorsement purposes. _____________________________________________________ The Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ Advisory Notice Virus Inadvertently Distributed in Novell Network Support Encyclopedia Update December 18, 1991 1000 PST Number C-11 _________________________________________________________________________ PROBLEM: 5 1/4 inch diskettes sent from Novell to customers from December 9 - 16, 1991 contain the Stoned-3 virus. PLATFORM: PC/MS-DOS systems running Novell Netware software. DAMAGE: Potential to overwrite boot sector of fixed and floppy disks; potential to create infected floppyless boot image files and thereby propagate the virus via the network. SOLUTION: Scan all incoming software. DETECTION/ERADICATION: Data Physician Plus, other antiviral packages. __________________________________________________________________________ Critical Facts about Inadvertent Virus Distribution CIAC has learned that Novell, Inc. has inadvertently sent diskettes infected with the Stoned-3 virus to Novell Netware customers. These diskettes are labelled "Network Support Encyclopedia - Standard Volume Update." The Novell part number for these disks is 883-001495-004. Infected diskettes were distributed from December 9 - 16, 1991. The Stoned-3 virus is a minor variation of the Stoned virus. This virus infects the boot sector of a hard disk or diskette and will sometimes display the message (sic): "Your PC is now Stoned!.....LEGALISE MARIJUANA!" This virus becomes memory resident and will infect any other disks accessed by the PC while the virus is memory resident. For additional information, please see CIAC bulletins A-28 for more information on the Stoned virus family, and B-16 for a summary of known viruses. If you discover that the Stoned virus has infected your PC, it may be removed using the VIRHUNT package licensed to DOE by Digital Dispatch Incorporated. CIAC also recommends that you follow a policy of scanning all new software before using or installing it on your PC. This policy should be followed for all vendor-supplied shrink-wrapped software as well as bulletin board or shareware software, since a few other vendors have inadvertently distributed viruses with packaged software in the past. CIAC recommends that if you are from a DOE site and are not already using an effective anti-viral scanner, you should contact your site's computer security department to obtain a free copy of Data Physician PLUS! (which contains VIRHUNT and several other useful packages). In addition, since new viruses are constantly being discovered, we recommend that you ensure that your anti-viral scanner has been updated to the most recent version. The most recent version of Data Physician PLUS! is V 3.0C. For additional information or assistance, please contact CIAC: Karen Pichnarczyk Tom Longstaff (510)422-1779** or (FTS) 532-1779 (510)423-4416** or (FTS) 543-4416 karyn@cheetah.llnl.gov longstaf@llnl.gov (FAX) (510) 423-8002** or (FTS) 543-8002 Send e-mail to ciac@llnl.gov or call CIAC at (510) 422-8193**/(FTS)532-8193. **Note area code has changed from 415, although the 415 area code will work until Jan. 1992. PLEASE NOTE: Many users outside of the DOE and ESnet computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Some of the other teams include the NASA NSI response team, DARPA's CERT/CC, NAVCIRT, and the Air Force response team. Your agency's team will coordinate with CIAC. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the University of California, and shall not be used for advertising or product endorsement purposes. _____________________________________________________ The Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ Information Bulletin Hewlett Packard/Apollo Domain/OS crp Vulnerability December 20, 1991 1000 PST Number C-12 _________________________________________________________________________ PROBLEM: The crp facility on Domain/OS systems is vulnerable to network attack PLATFORM: Hewlett Packard/Apollo Domain/OS SR10 systems through version SR10.3 (both UNIX and AEGIS systems are affected) DAMAGE: An authorized user at a remote or local site can obtain the privileges of the user running crp on a Domain/OS system SOLUTION: The workaround provided below should be applied to all Domain/OS systems supporting crp until a patch is available from HP/Apollo. __________________________________________________________________________ Critical Facts about crp vulnerability CIAC has learned of a workaround to a vulnerability which exists in the Hewlett Packard/Apollo (HP/Apollo) Domain/OS crp facility. Failure to close this vulnerability may allow an unauthorized remote or local user to obtain the privileges of a user running crp on a Domain/OS system. Both the UNIX and AEGIS version of the Domain/OS systems are affected by this vulnerability. A patch is under development by HP/Apollo and should be available in the SR10.3 patch tape (planned release is February 1992). This patch will be incorporated in the next major release of HP/Apollo Domain/OS. Until the patch is available from the vendor, CIAC recommends that all HP/Apollo Domain/OS systems apply the following workaround. This workaround will disable two system calls made by /usr/apollo/bin/crp. Consequently, the functionality of various software programs may be affected, since the workaround will disable the ability to define programmable function keys, create new windows on the client node, or execute background processes using the Display Manager interface. In the description of the workaround below, the specific commands applicable to the UNIX or AEGIS version of Domain/OS will be identified. 1. Create a file "crplib.c" containing the following: extern void pad_$dm_cmd(void); void pad_$dm_cmd() { } extern void pad_$def_pfk(void); void pad_$def_pfk() { } 2. Compile this program using the '-pic' option of the C compiler (AEGIS) /com/cc crplib.c -pic (UNIX) /bin/cc -c crplib.c -WO -pic 3. Copy the resulting library to /lib/crplib or other standard library location on the system and change the permission on the file to allow user to link to the library (AEGIS) /com/cpf crplib.bin /lib/crplib (AEGIS) /com/edacl -p root prwx -g wheel rx -w rx /lib/crplib (UNIX) /bin/cp crplib.o /lib/crplib (UNIX) /bin/chmod 755 /lib/crplib 4. Replace the original crp facility with a script that will do an 'inlib' of the created library file before running crp. (AEGIS) /com/chn /usr/apollo/bin/crp crp.orig (UNIX) /bin/mv /usr.apollo/bin/crp /usr/apollo/bin/crp.orig 5. Create a file '/usr/apollo/bin/crp' containing the following: (AEGIS) #!/com/sh /com/sh -c inlib /lib/crplib ';' /usr/apollo/bin/crp.orig^* (UNIX) #!/bin/sh inlib /lib/crplib exec /usr/apollo/bin/crp.orig "$@" 6. Change the permissions on this script file to make it accessible to users on the system as a replacement for the original crp facility (AEGIS) /com/edacl -p root prwx -g wheel rx -w rx /usr/apollo/bin/crp (UNIX) /bin/chmod 755 /usr/apollo/bin/crp For additional information or assistance, please contact CIAC: Tom Longstaff (510)423-4416** or (FTS) 543-4416 longstaf@llnl.gov (FAX) (510) 423-8002** or (FTS) 543-8002 Send e-mail to ciac@llnl.gov or call CIAC at (510) 422-8193**/(FTS)532-8193. **Note area code has changed from 415, although the 415 area code will work until Jan. 1992. PLEASE NOTE: Many users outside of the DOE and ESnet computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Some of the other teams include the NASA NSI response team, DARPA's CERT/CC, NAVCIRT, and the Air Force response team. Your agency's team will coordinate with CIAC. CIAC would like to thank the Computer Emergency Response Team/Coordination Center (CERT/CC) for some of the material provided in this bullein. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the University of California, and shall not be used for advertising or product endorsement purposes. _____________________________________________________ The Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ Information Bulletin NeXTstep NetInfo Configuration Vulnerability January 21, 1991 1400 PST Number C-13 _________________________________________________________________________ PROBLEM: By default, the NetInfo server process allows unrestricted access to system databases. PLATFORM: NeXT computers with release 2 of NeXTstep operating system. DAMAGE: Remote users can gain unauthorized access to the network's administrative information such as the passwd database. SOLUTION: Correctly configure NetInfo directory so that that the trusted_networks property is set only to the network IP addresses your server trusts. __________________________________________________________________________ Critical Facts about NeXT NetInfo vulnerability CIAC has learned of a configuration vulnerability in release 2 of the NeXTstep operating system for NeXT computers. Because a NetInfo server process will by default allow unrestricted access to system databases, remote users can gain unauthorized access to the network's administrative information. For example, if a NeXT computer (or LAN) grants external access to other TCP/IP networks, information about hosts and users in NetInfo can be used by remote attackers to compromise the security of the local network and hosts connecting to it. For example, an unauthorized user can also remotely obtain the NetInfo password database (NetInfo /users directory) if default settings are not changed as described below. NeXT Computers Inc. recommends that each domain that stores user passwords be protected against outside access. To accomplish this, ensure that the trusted_networks property of each NetInfo domain's root NetInfo directory is set correctly, so that only systems trusted to obtain information from NetInfo are granted access. The value for the trusted_networks property should be the network address (see step 7 below) of the networks the server should trust. You should consult Chapter 16, "Security", of the "NeXT Network and System Administration" manual for release 2 for detailed procedures concerning setting the trusted_networks property of the root NetInfo directory. The following will, however, provide a brief overview of these procedures for NeXT administrators already familiar with these procedures (which must be performed with root privilege): 1. With NetInfoManager, open the domain to be protected. Click the root directory. 2. Choose Open Directory from the Directory menu. 3. Click "master" in the Properties column 4. Choose Append Property. Notice the Property called "new_property" 5. Click that property. Change the text in the field at the bottom of the window from "new_property" to "trusted_networks". Press to record the change. 6. Choose New Value from the Directory menu. Notice the value in the Values column called "new_value". 7. Click "new_value" in the values column. Change the text in the field at the bottom of the window from "new_value" to your network address. This is the section of the Internet address which belongs to the network. Enter the number assigned to you from the NIC or Corporate Network Manager. Do not include a trailing period in the network number. Press to record the change. 8. Save the directory by choosing Save in the Directory menu. WARNING: If you incorrectly enter this number, it may result in legitimate machines being unable to boot or read administrative information. If you are in doubt to these instructions refer to to the manual described above. CAUTION: Improperly setting trusted_networks can render your network unusable. For additional information or assistance please contact CIAC. Send e-mail to ciac@llnl.gov or call CIAC at (510)422-8193**/(FTS)532-8193. David S. Brown (510)423-9878** or (FTS) 543-9878 dsbrown@llnl.gov (FAX) (510) 423-8002** or (FTS) 543-8002 **Note area code has changed from 415, although the 415 area code will work until Jan. 27, 1992. PLEASE NOTE: Many users outside of the DOE and ESnet computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Some of the other teams include the NASA NSI response team, DARPA's CERT/CC, NAVCIRT, and the Air Force response team. Your agency's team will coordinate with CIAC. CIAC would like to thank Alan Marcum of NeXT Computer Inc. and the Computer Emergency Response Team/ Coordination Center (CERT/CC) for some of the material provided in this bulletin. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the University of California, and shall not be used for advertising or product endorsement purposes. _____________________________________________________ The Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ Information Bulletin Michelangelo Virus on MS DOS Computers February 6, 1992, 1400 PDT Number C-15 _________________________________________________________________________ Name: Michelangelo virus Platform: MS-DOS computers Damage: On March 6 will destroy all files on infected disks and diskettes that are accessed. Symptoms: CHKDSK reports "total bytes memory" 2048 bytes less than expected Detection: DDI Data Physician Plus! v 3.0C, FPROT 2.01, other anti-viral packages updated since late September 1991 Eradication: DDI Data Physician Plus! v 3.0C, FPROT 2.01, other anti-viral packages updated since late September 1991 _________________________________________________________________________ Critical Facts about Michelangelo Virus The Michelangelo virus, one of the most widespread viruses among MS DOS systems, infects the Master Boot Record of hard disks and the boot sector of floppy disks. This virus will destroy infected disks on March 6 (Michelangelo's birthday). It infects very rapidly and quietly, usually showing no indication of its presence until a virus detection utility notes its existence. Infection Mechanism This virus is very similar to the Stoned family of viruses (see CIAC Bulletin A-28 for a description of the Stoned virus). When a Michelangelo-infected diskette is placed in the A: drive and the machine is booted, the virus is loaded into memory from the infected floppy disk. It then quickly infects the machine by moving the hard disk's original boot sector to another location on the disk, and installs itself as the boot sector. From then on, any access to another disk spreads the virus to that disk. The disk which infects the hard disk does NOT have to be a bootable system diskette to spread the infection. Also, all boot infector viruses, such as this one, do NOT affect user files, therefore, a backup prior to eradication will enable full recovery of all user data and programs. Potential Damage On March 6 of any year this virus will destroy all data on any disk from which the machine is booted. This occurs by overwriting hard disk sectors 1-17, heads 0-3, tracks 0-255, or the entire diskette with random characters, thus making recovery questionable at best. Note that if your hard disk is partitioned and contains another operating system, such as UNIX, in the area overwritten, that data will be destroyed as well. On all other days of the year this virus lays dormant, merely copying itself to other disks. The infection mechanism of this virus may also cause read errors to occur upon some high density (1.2 M) diskettes. A problem can occur if a disk is infected by both the Michelangelo and the Stoned viruses AT THE SAME TIME. Both move the 'original' boot sector to the same location on the disk, so when the second infection occurs, the original clean boot sector is destroyed by being overwritten by the first virus. CIAC recommends a low-level format of the disk if this double-infection occurs, although performing the DOS SYS operation may repair a damaged diskette, and performing the undocumented FDISK/MBR operation (in DOS 5.0 only) may repair a damaged hard disk. Detection and Eradication Because the Michelangelo virus has been discovered relatively recently, only anti-virus products updated since early autumn of 1991 will detect it. If you suspect your PC has this virus and do not have an updated version of a virus scanner, running CHKDSK will report a "total bytes memory" value 2048 bytes less than expected. For example, a PC with 640 KBytes of memory will normally return a value of 655,360 bytes, with Michelangelo that value would be 653,312. Of course, having less "total bytes memory" does not necessarily mean a virus is resident on your machine, as some valid memory resident programs can affect this value as well. CIAC is aware of at least two publicized cases of this virus being inadvertently distributed by vendors. The vendors involved are Leading Edge and DaVinci Systems; both vendors have made an attempt to contact all recipients of the software involved. CIAC stresses the importance of checking all incoming diskettes with an anti-viral utility, such as VIRHUNT from DDI's Data Physician Plus! package. CIAC recommends that once a system has had a virus eradicated, it be powered down. The computer should then be observed closely throughout the entire boot-up process. Another virus scan should be performed on the machine to ensure that it is devoid of any virus. For additional information or assistance, please contact CIAC: Karyn Pichnarczyk (510) 422-1779 or (FTS) 532-1779 karyn@cheetah.llnl.gov (FAX) (510) 423-8002 or (FTS) 543-8002 Send e-mail to ciac@llnl.gov or call CIAC at (510)422-8193/(FTS)532-8193. PLEASE NOTE: Many users outside of the DOE and ESnet computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Some of the other teams include the NASA NSI response team, DARPA's CERT/CC, NAVCIRT, and the Air Force response team. Your agency's team will coordinate with CIAC. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the University of California, and shall not be used for advertising or product endorsement purposes. NO RESTRICTIONS _____________________________________________________ The Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ INFORMATION BULLETIN New Internet Intrusions Detected February 19, 1992, 1100 PDT Number C-16 ________________________________________________________________________ PROBLEM: A new series of probes and penetrations on systems connected to the Internet has been detected. PLATFORM: Primarily UNIX systems. DAMAGE: Trojan Horse programs replacing the su, ftp, and ftpd utilities are common, other Trojan Horse programs detected include telnet and login. Information on penetrated accounts have been posted to public bulletin board systems. SOLUTIONS: Verify that the utilities mentioned have not been modified by comparing them with copies on the distribution media. Also check for the existence of /usr/etc/... (dot, dot, dot), /var/crash/..., /usr/etc/.getwd, /var/crash/.getwd, or /usr/kvw/... ________________________________________________________________________ Critical Information About Internet Intrusions CIAC has learned of a new series of Internet attacks involving primarily UNIX systems. The intruder is using vulnerabilities such as TFTP (see CIAC bulletin A-19, A-21, B-44, and B-45 for more details) to obtain copies of the password file on some Internet systems. The passwords are then checked to see if any are easily guessed, and if so, the account is used to gain access to the system. These attacks are widespread, and accounts penetrated by these intruders are used to attack other systems or gain root privilege on the penetrated system. If the intruder gains root privilege, system binaries for the utilities su, ftp, and ftpd may be replaced with Trojan Horse versions that record subsequent passwords entered by legitimate users. In addition the intruder may post the username, password, and system name of the penetrated account to a public bulletin board system. If you manage a UNIX system connected to the Internet, CIAC recommends that you verify that the system binaries for the su, ftp, and ftpd utilities have not been modified. This can be done by comparing the binaries to those on the system distribution media or by using a CRC package such as contained in SPI/UNIX (available at no cost to DOE sites) to assure that the binaries have not been modified. Another indication of this attack is the presence of files ... (dot, dot, dot) in either the /usr/etc, /var/crash, or /usr/kvw directories or the file .getwd in the /usr/etc/ or /var/crash directories. Other indicators of this attack include: o Presence of set-uid root shells named .a or wtrunc anywhere on the system o Addition of a "+" in the /etc/hosts.equiv file o Addition of a .rhosts file in any home directory mentioned in the /etc/password file containing the string "+ +" (plus, space, plus) o Presence of a set-uid root file /usr/lib/lpx Should you encounter any of the above mentioned indicators of this attack, CIAC recommends that you save a copy of the affected files on tape or other removable media, remove or replace these files with binaries from the system distribution media, and contact CIAC at the number listed below. In addition, all passwords on the system should be changed. CIAC recommends that you run the SPI/UNIX or comparable package to verify that your passwords are robust and system binaries have not been modified. Version 2.0 of SPI/UNIX has been released and is available at no cost to the DOE community. Contact your local Computer Security department or CIAC for assistance in obtaining or installing this product. For additional information or assistance, please contact CIAC: Tom Longstaff (510) 423-4416/(FTS) 543-4416 longstaf@llnl.gov Call CIAC at (510) 422-8193/(FTS) 532-8193 or send e-mail to ciac@llnl.gov. FAX messages to: (510) 423-8002/(FTS) 543-8002. Previous CIAC bulletins and other information is available via anonymous ftp from irbis.llnl.gov (ip address 128.115.19.60). PLEASE NOTE: Many users outside of the DOE and ESnet computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Some of the other teams include the NASA NSI response team, DARPA's CERT/CC, NAVCIRT, and the Air Force response team. Your agency's team will coordinate with CIAC. The Computer Emergency Response Team/Coordination Center (CERT/CC) provided some of the information used in this bulletin. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the University of California, and shall not be used for advertising or product endorsement purposes. NO RESTRICTIONS _____________________________________________________ The Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ INFORMATION BULLETIN New Virus on Macintosh Computers: MBDF A February 25, 1992, 1130 PST Number C-17 ________________________________________________________________________ NAME: MBDF A virus PLATFORM: Macintosh computers-except MacPlus and SE (see below) DAMAGE: May cause program crashes SYMPTOMS: Claris applications indicate they have been altered; some shareware may not work, unexplained system crashes DETECTION & ERADICATION: Disinfectant 2.6,Gatekeeper 1.2.4, Virex 3.6, VirusDetective 5.0.2, Rival 1.1.10, SAM 3.0 ________________________________________________________________________ Critical Facts about MBDF A A new Macintosh virus, MBDF A, (named for the resource it exploits) has been discovered. This virus does not appear to maliciously cause damage, but simply copies itself from one application to another. MBDF A was discovered at two archive sites in newly posted game applications, and has a high potential to be very widespread. Infection Mechanism This virus is an "implied loader" virus, and it works in a similar manner to other implied loader viruses such as CDEF and MDEF. Once the virus is active, clean appliacation programs will become infected as soon as they are executed. MBDF A infects only applications, and does not affect data files. This virus replicates under both System 6 and System 7. While MBDF A may be present on ALL types of Macintosh systems, it will not spread if the infected system is a MacPlus or a Mac SE (although it does spread on an SE/30). Potential Damage The MBDF A virus has no malicious damaging characteristics, however, it may cause programs to inexplicably crash when an item is selected from the menu bar. Some programs, such as the shareware "BeHierarchic" program, have been reported to not operate correctly when infected. Applications written with self-checking code, such as those written by the Claris corporation, will inform the user that they have been altered. When MBDF A infects the system file, it must re-write the entire system file back to disk; this process may take two or three minutes. If the user assumes the system has hung, and reboots the Macintosh while this is occuring, the entire system file will be corrupted and an entire reload of system software must then be performed. This virus can be safely eradicated from most infected programs, although CIAC recommends that you restore all infected files from an uninfected backup. Detection and Eradication Because MBDF A has been recently discovered, only anti-viral packages updated since February 20, 1992 will locate and eradicate this virus. All the major Macintosh anti-viral product vendors are aware of this virus and have scheduled updates for their products. These updates have all been available since February 24, 1992. The updated versions of some products are Disinfectant 2.6, Gatekeeper 1.2.4, Virex 3.6, SAM 3.0, VirusDetective 5.0.2, and Rival 1.1.10. Some Macintosh applications (such as the Claris software mentioned above) may contain self-verification procedures to ensure the program is valid before each execution; these programs will note unexpected alterations to their code and will inform the user. MBDF A has been positively identified as present in two shareware games distributed by reliable archive sites: "Obnoxious Tetris" and "Ten Tile Puzzle". The program "Tetricycle" (sometimes named "Tetris-rotating") is a Trojan Horse program which installs the virus. If you have downloaded these or any other software since February 14, 1992 (the day these programs were loaded to the archive sites), CIAC recommends that you acquire an updated version of an anti-viral product and scan your system for the existence of MBDF A. For additional information or assistance, please contact CIAC: Karyn Pichnarczyk (510) 422-1779 or (FTS) 532-1779 karyn@cheetah.llnl.gov Call CIAC at (510)422-8193/(FTS)532-8193. Send e-mail to ciac@llnl.gov PLEASE NOTE: Many users outside of the DOE and ESnet computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Some of the other teams include the NASA NSI response team, DARPA's CERT/CC, NAVCIRT, and the Air Force response team. Your agency's team will coordinate with CIAC. CIAC would like to thank Gene Spafford and John Norstad, who provided some of the information used in this bulletin. This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes. NO RESTRICTIONS _____________________________________________________ The Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ INFORMATION BULLETIN Vulnerability In AT&T /usr/etc/rexecd February 25, 1992, 1100 PDT Number C-18 ________________________________________________________________________ PROBLEM: A vulnerability exists in AT&T /usr/etc/rexecd PLATFORM: AT&T TCP/IP Release 4.0 running on SVR4 systems for both the 386/486 and 3B2 RISC platforms. DAMAGE: misuse of /usr/etc/rexecd may allow a user on a remote machine to run commands as root on the target host (the host running the affected /usr/etc/rexecd). SOLUTIONS: Disable the vulnerable program until a replacement or patch is obtained. ________________________________________________________________________ Critical Information About ATT /usr/etc/rexecd CIAC has learned of a new vulnerability in AT&T TCP/IP Release 4.0 running on SVR4 systems for both the 386/486 and 3B2 RISC platforms. The existing error, in the remote execution server /usr/etc/rexecd, has been corrected, and a new executable for rexecd is available from AT&T by calling 800-543-9935. Patches may be obtained outside the U.S. by calling your local technical support. The numbers associated with the fix are 5127 (3.5" media) and 5128 (5.25" media). Administrators of affected systems should execute, as root, the following command to immediately turn off access to rexecd until the new binary can be obtained. # chmod 400 /usr/etc/rexecd You may then obtain and install the new patch. The fix will be supplied as one diskette, and it comes with one page of instructions documenting the procedure for replacing the existing /usr/etc/rexecd binary. The problem does not exist in TCP/IP release 3.2 for SVR3, or any earlier versions of the TCP/IP product running on either the 3B2 or 386 platforms. In addition, the version of TCP/IP distributed with SVR4 by UNIX(r) System Laboratories, Inc. (a subsidiary of AT&T) does not contain this vulnerability. UNIX(r) is a registered trademark of UNIX System Laboratories, Inc. For additional information or assistance, please contact CIAC: David Brown (510) 423-9878/(FTS) 543-9878 dsbrown@llnl.gov Call CIAC at (510) 422-8193/(FTS) 532-8193 or send e-mail to ciac@llnl.gov. FAX messages to: (510) 423-8002/(FTS) 543-8002. Previous CIAC bulletins and other information is available via anonymous ftp from irbis.llnl.gov (ip address 128.115.19.60). CIAC would like to thank Bradley E. Smith, Network & Technical Services, Bradley University, AT&T, and the CERT/CC for assistance with this bulletin. PLEASE NOTE: Many users outside of the DOE and ESnet computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Some of the other teams include the NASA NSI response team, DARPA's CERT/CC, NAVCIRT, and the Air Force response team. Your agency's team will coordinate with CIAC. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the University of California, and shall not be used for advertising or product endorsement purposes. _____________________________________________________ The Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ INFORMATION BULLETIN Vulnerabilities in SAS¨ System release 5.18 for VAX/VMS February 28, 1992, 1700 PT Number C-19 ________________________________________________________________________ PROBLEM: SAS System release 5.18 installation leaves its directories and startup file unprotected. PLATFORM: VAX/VMS systems with SAS System release 5.18 installed. DAMAGE: Unprivileged user could obtain all privileges. SOLUTIONS: Set directories [SAS518], [SAS518.TOOLS], and SAS518.COM to world-read, world-execute. ________________________________________________________________________ Critical Information About SAS 5.18 Vulnerability CIAC has learned of a vulnerability in SAS System release 5.18, distributed in 1988 for the VAX/VMS operating system. Subsequent releases (6 and above) do not have this problem. Release 5.18 is still in use and supported by the SAS Institute. Specifically, an installation of SAS System 5.18 will incorrectly set protections on directories [000000]SAS518.DIR and [SAS518]TOOLS.DIR, as well as its startup file [SAS518.TOOLS]SAS518.COM. CIAC recommends issuing the following commands from the SYSTEM account: $ SET PROTECTION=(S:RWE,O:RWE,G:RE,W:RE) disk_name:[000000]SAS518.DIR $ SET PROTECTION=(S:RWED,O:RWED,G:RE,W:RE) SAS$ROOT:[000000...]*.*;* SAS has sent an advisory notice to supported SAS installations. Additionally, SAS Note SYS.INST-V5722I documents this problem. If you wish to discuss this with SAS, call SAS Technical Support, 919-677-8008, and ask for a VMS Consultant (9 to 5 Eastern time). For additional information or assistance, please contact CIAC: Allan L. Van Lehn (510) 422-6652/(FTS) 542-6652 vanlehn3@llnl.gov Call CIAC at (510) 422-8193/(FTS) 532-8193 or send e-mail tociac@llnl.gov. FAX messages to: (510) 423-8002/(FTS) 543-8002. Previous CIAC bulletins and other information is available via anonymous ftp from irbis.llnl.gov (ip address 128.115.19.60). PLEASE NOTE: Many users outside of the DOE and ESnet computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Some of the other teams include the NASA NSI response team, DARPA's CERT/CC, NAVCIRT, and the Air Force response team. Your agency's team will coordinate with CIAC. CIAC wishes to thank John J Stafford and Maggie Underberg who provided some of the information used in this bulletin. This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes. SAS¨ is a registered trademark of the SAS Institute Inc., SAS Campus Drive, Cary, NC 27513. DISTRIBUTION RESTRICTIONS: PUBLIC DISTRIBUTION __________________________________________________ The Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ Information Bulletin SGI 3.3.X Pseudo-tty Vulnerability March 6, 1992 1000 PST Number C-20 _________________________________________________________________________ PROBLEM: Non-root users have the ability to see the output of other users terminal activity. PLATFORM: Silicon Graphics systems running IRIX 3.3.X (3.3.1, 3.3.2 and 3.3.3L) DAMAGE: Potential disclosure of user sensitive data including passwords. SOLUTION: SGI MIPS based machines should upgrade to 4.0.1 or to Trusted Irix. __________________________________________________________________________ Critical Facts about SGI 3.3.X Pseudo tty Vulnerability CIAC has become aware of a possible security problem with Silicon Graphics systems running IRIX 3.3.X (3.3.1, 3.3.2 and 3.3.3L). This problem has been fixed under 4.0.1. The IRIX psuedo-ttys (pttys) are protected mode 0666, which permits non-root users to read unprotected terminals. This might permit non- authorized users to see confidential information, including passwords. SGI and CIAC recommend that you upgrade your 3.3.X system either to 4.0.1 or to Trusted Irix immediately. Contact your SGI representative, or SGI Express (1-800-800-SGI1). SGI customers under support may call 1-800-800-4744 (1-800-800-4SGI) Note, if you suspect that another user is reading from your terminal, you may use the command: fuser -u `tty`. This shows what processes are connected to your tty, see fuser(8). You should be able to account for each of them using the ps(1) command. For additional information or assistance, please contact CIAC: David Brown (510) 423-9878/(FTS) 543-9878 dsbrown@llnl.gov Call CIAC at (510) 422-8193/(FTS) 532-8193 or send e-mail to ciac@llnl.gov. FAX messages to: (510) 423-8002/(FTS) 543-8002. Previous CIAC bulletins and other information is available via anonymous ftp from irbis.llnl.gov (ip address 128.115.19.60). PLEASE NOTE: Many users outside of the DOE and ESnet computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Some of the other teams include the NASA NSI response team, DARPA's CERT/CC, NAVCIRT, and the Air Force response team. Your agency's team will coordinate with CIAC. CIAC would like to thank Lisa Amedeo of Fermi National Laboratory, and Debby Derby of Silicon Graphics Inc. for their assistance with this bulletin. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the University of California, and shall not be used for advertising or product endorsement purposes. DISTRIBUTION RESTRICTIONS: PUBLIC DISTRIBUTION _______________________________________________________ The Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ Information Bulletin AIX REXD Daemon Vulnerability March 6, 1992 1000 PST Number C-21 _________________________________________________________________________ PROBLEM: In certain configurations the rexd (RPC remote program execution) daemon is enabled. PLATFORM: IBM AIX 3.1 and 3.2. DAMAGE: Anyone can remotely gain access to the system as a user other than root. SOLUTION: Apply fix below. __________________________________________________________________________ Critical Facts about AIX REXD Daemon Vulnerability CIAC has become aware of a possible security problem with the rexd daemon in versions 3.1 and 3.2 of AIX for IBM RS/6000 machines. In certain configurations, particularly if NFS is installed, the rexd (RPC remote program execution) daemon is enabled. Also note that, installing NFS with the current versions of "mknfs" will re-enable rexd even if it was previously disabled. IBM is aware of the problem and will fix it in future updates to AIX 3.1 and 3.2. Sites may call IBM Support (800-237-5511) and ask for the patch for apar ix21353. Patches may be obtained outside the U.S. by contacting your local IBM representative. Until you receive this patch, the following should correct the problem. IBM and CIAC recommend that sites take the following actions immediately. These steps should also be taken whenever "mknfs" is run. 1. Be sure the rexd line in /etc/inetd.conf is commented out by having a '#' at the beginning of the line: #rexd sunrpc_tcp tcp wait root /usr/etc/rpc.rexd rexd 100017 1 2. Refresh inetd by running the following command as root: refresh -s inetd For additional information or assistance, please contact CIAC: David Brown (510) 423-9878/(FTS) 543-9878 dsbrown@llnl.gov Call CIAC at (510) 422-8193/(FTS) 532-8193 or send e-mail to ciac@llnl.gov. FAX messages to: (510) 423-8002/(FTS) 543-8002. Previous CIAC bulletins and other information is available via anonymous ftp from irbis.llnl.gov (ip address 128.115.19.60). PLEASE NOTE: Many users outside of the DOE and ESnet computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Some of the other teams include the NASA NSI response team, DARPA's CERT/CC, NAVCIRT, and the Air Force response team. Your agency's team will coordinate with CIAC. CIAC would like to thank Darren Reed of the Australian National University and the Computer Emergency Response Team/Coordination Center (CERT/CC) for their assistance with this bulletin. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the University of California, and shall not be used for advertising or product endorsement purposes. _______________________________________________________ The Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ Information Bulletin Patch Available for SunOS ypserv, ypxfrd, and portmap May 27, 1992 0900 PDT Number C-25 __________________________________________________________________________ PROBLEM: Bugs in ypserv, ypxfrd, and portmap permit NIS maps to be obtained by unauthorized individuals. PLATFORM: All Sun3 and Sun4 computers running SunOS 4.1, 4.1.1, or 4.1.2 DAMAGE: Any user may obtain the password map. SOLUTION: Apply patch available from Sun. __________________________________________________________________________ Critical Facts about SunOS patch for ypserv, ypxfrd, and portmap. Sun Microsystems has announced the availability of a new patch for the ypserv, ypxfrd, and portmap utilities. If not patched, these utilities may permit unauthorized distribution of NIS maps, including the password map. The patch is available from Sun Microsystems as Patch ID# 100482-02. This patch, along with other Sun patches, is available both through your local Sun answer centers and though anonymous ftp. In the US, ftp to ftp.uu.net and retrieve the patch from the directory ~ftp/systems/sun/sun-dist. In Europe, ftp to mcsun.eu.net and retrieve the patch from the ~ftp/sun/fixes directory. The patch is contained in the compressed tarfile 100482-02.tar.Z, and must be retrieved in binary mode, then uncompressed and untarred on the local system: local% ftp ftp.uu.net Connected to ftp.uu.net... Name: ftp Password: ftp> cd ~ftp/systems/sun/sun-dist ftp> binary ftp> get 100482-02.tar.Z ftp> bye local% uncompress 100482-02.tar.Z local% tar xf 100482-02.tar The checksum of the compressed tarfile is 53416 284. This patch includes new versions of the utilities ypserv, ypxfrd, and portmap. To install the patch on your system, follow the instructions available in the README file which accompanies the patch. For additional information or assistance, please contact CIAC: Steve Weeber (510) 423-9878 (Commercial/FTS) weeber@llnl.gov Call CIAC at (510) 422-8193 (Commercial/FTS) or send e-mail to ciac@llnl.gov. FAX messages to: (510) 423-8002 (Commercial/FTS). Previous CIAC bulletins and other information is available via anonymous ftp from irbis.llnl.gov (ip address 128.115.19.60). PLEASE NOTE: Many users outside of the DOE and ESnet computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Some of the other teams include the NASA NSI response team, DARPA's CERT/CC, NAVCIRT, and the Air Force response team. Your agency's team will coordinate with CIAC. CIAC would like to thank Kenneth Pon of Sun Microsystems for his assistance with this bulletin. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the University of California, and shall not be used for advertising or product endorsement purposes. _____________________________________________________ The Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ Information Bulletin SunOS Environment Variables and setuid/setgid Vulnerability May 27, 1992, 1500 PDT Number C-26 _________________________________________________________________________ PROBLEM: User environment variables can be used to subvert security. PLATFORM: All Sun3/Sun4 computers running SunOS 4.1, 4.1.1, or 4.1.2 DAMAGE: Local users can obtain unauthorized privileges. SOLUTION: Install environment wrapper (included) and/or apply patchs. _________________________________________________________________________ Critical Information about Shared Libraries CIAC has obtained information concerning a security problem with shared libraries (i.e., dynamically-linked programs). User environment variables are improperly passed to SETUID and SETGID programs. This vulnerability applies to in-house, third-party, and Sun SETUID/SETGID applications that change the real ID and effective ID to match before executing the program. The programs known by SUN to have this problem in SunOS 4.1.x are: /usr/lib/sendmail, /usr/bin/login, /usr/bin/su, /usr/5bin/su. Patch ID# FILE CHECKSUM VERSION ---------- --------------- ----------- ------------------------------ 100377-04 100377-04.tar.Z 14692 311 sendmail 100630-01 100630-01.tar.Z 36269 39 login/su, International version 100631-01 {contact SUN Answer Center}* login/su, Domestic version * Export regulations prohibit distributing 100631-01 via anonymous ftp. Please contact your SUN Answer Center for Patch ID# 100631-01 If you do not have ready access to the patches listed above or have third party software that may be vulnerable, CIAC recommends that you wrap executables in the enclosed wrapper code, provided by Wietse Venema, Eindhoven University of Technology, The Netherlands. It is highly recommended that the wrapper program be installed around your applicable ARM versions of the affected programs. These patches, as well as all other Sun patches, are available both through your local Sun Answer Centers and via anonymous ftp. In the US, ftp to ftp.uu.net (137.39.1.9) and retrieve the patch from the directory ~ftp/systems/sun/sun-dist. In Europe, ftp to mcsun.eu.net (192.16.202.1) and retrieve the patch from the ~ftp/sun/fixes directory. For additional information or assistance, please contact CIAC: Marvin J. Christensen (510) 423-5173 or (FTS) 543-5173 send e-mail to mjchristensen@llnl.gov CIAC at (510) 422-8193/(FTS) FAX (510) 423-8002/(FTS) send e-mail to ciac@llnl.gov. Previous CIAC bulletins and other information is available via anonymous ftp from irbis.llnl.gov (ip address 128.115.19.60). =========================================================================== /* * Remove "LD_" variables from user environment before calling a * SETUID/SETGID executable * * This code is specific to /bin/login, but can be easily modified to * wrap other programs by modifying "COMMAND". Change the value of * "COMMAND" to the new, full path name of the command that you want * to wrap after you have moved it. For example, if you moved * /usr/lib/sendmail to /usr/lib/sendmail+ (using the command "mv * /usr/lib/sendmail /usr/lib/sendmail+"), change the macro definition * of "COMMAND" in the C program to: * * #define COMMAND "/usr/lib/sendmail+" * * Then perform the steps below to compile and install your * sendmail wrapper. */ #define COMMAND "/bin/login+" main(argc,argv) int argc; char **argv; { fixenv(); execv(COMMAND,argv); perror(COMMAND); exit(1); } fixenv() { extern char **environ; char **cpp; char **xpp; char *cp; for (cpp = environ; cp = *cpp; cpp++) { while (*cp++ == 'L' && *cp++ == 'D' && *cp == '_') { for (xpp = cpp; xpp[0] = xpp[1]; xpp++) /* void */ ; if ((cp = *cpp) == 0) return; } } } /*----------------------------------------------------------------*/ The example code above is specific to /bin/login. Install as root: Move the old /bin/login to /bin/login+ and modify permissions: # mv /bin/login /bin/login+ # chmod 750 /bin/login+ Put the code above in a C program file and compile. For this example assume the file is /tmp/login.c: # cd /tmp # make login Move the wrapper program into /bin/login and modify permissions and ownership: # mv /tmp/login /bin/login # chown root.staff /bin/login # chmod 4711 /bin/login =========================================================================== CIAC would like to acknowledge the contributions of: CERT/CC, PCERT, SUN Microsystems, and Wietse Venema. PLEASE NOTE: Many users outside of the DOE and ESnet computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Some of the other teams include the NASA NSI response team, DARPA's CERT/CC, NAVCIRT, and the Air Force response team. Your agency's team will coordinate with CIAC. This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes. _____________________________________________________ The Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ INFORMATION BULLETIN PKZIP Trojan Alert JULY 8, 1992, 1700 PT Number C-27 ________________________________________________________________________ PROBLEM: Bogus versions of the PKZIP archiving software have been released to Bulletin Board Systems (BBS). PLATFORM: PCs running PC-DOS, or MS-DOS DAMAGE: One version attempts to erase the hard disk. DETECTION: Look for the files: PKZ201.ZIP, PKZ201.EXE, PKZIPV2.ZIP, or PKZIPV2.EXE REMOVAL: Save a copy of the files for CIAC, then delete the files. Do not extract or run these files. ________________________________________________________________________ Critical Facts about the PKZIP Trojan CIAC has learned that two bogus versions of the popular archiving utility PKZIP for PC-DOS and MS-DOS machines are being circulated on several BBSs around the country. The two bogus versions of PKZIP are, 2.01 (PKZ201.ZIP and PKZ201.EXE) and 2.2 (PKZIPV2.ZIP and PKZIPV2.EXE). If you have downloaded any of these files, do not attempt to use them. You risk the destruction of all the data on your hard disk if you do. At the current time, the released version of PKZIP is version 1.10. A new version of PKZIP is expected to be released in the next few months. Its version number was planned to be 2.00, but may be increased to a number greater than 2.2 to prevent confusion with the bogus versions. PKWARE Inc. has indicated it will never issue a version 2.01 or 2.2 of PKZIP. A good copy of the latest version of PKZIP can always be gotten from the PKWARE BBS listed below. According to PKWARE Inc. version 2.01 is a hacked version of PKZIP 1.93 Alpha. While this version does not intentionally do any damage, it is alpha level software, and may have serious bugs in it. Version 2.2 is a simple batch file that attempts to erase your C:\ and C:\DOS directories. If your hard disk has been erased by this program, you may be able to recover it using hard disk undelete utilities such as those in Norton Utilities, or PCTools. Don't do anything that might create or expand a file on your hard disk until you have undeleted the files, as you may overwrite the deleted files which will destroy them. To examine a file to see if it is version 2.2, type it to the screen with the DOS TYPE command. If the file that prints on the screen is a short batch file with commands such as DEL C:\*.*, or DEL C:\DOS\*.* then you have the bogus file. If you should happen to see any of these files on a BBS, please contact the sysop of that BBS immediately, and ask him to remove them. If you have downloaded one of these files, please save a copy for CIAC, and then delete the files from your hard disk. PKWARE Inc. has also asked to be informed of any occurrences of these files, and can be reached at, Voice: 414-354-8699 BBS: 414-354-8670 FAX: 414-354-8559 or by mail: PKWARE Inc. 9025 N. Deerwood Drive Brown Deer, WI 53223 USA For additional information or assistance, please contact CIAC: CIAC at (510) 422-8193/(FTS) FAX (510) 423-8002/(FTS) send e-mail to ciac@llnl.gov. Previous CIAC bulletins and other information is available via anonymous ftp from irbis.llnl.gov (ip address 128.115.19.60). PLEASE NOTE: Many users outside of the DOE and ESnet computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Some of the other teams include the NASA NSI response team, DARPA's CERT/CC, NAVCIRT, and the Air Force response team. Your agency's team will coordinate with CIAC. CIAC would like to acknowledge the contribution of: PKWARE Inc. This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes. _______________________________________________________ The Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ Information Bulletin SunOS Security Patches July 27, 1992 1500 PDT Number C-28 __________________________________________________________________________ PROBLEMS: 1. Sparc integer multiplication and division can be used to gain root access. 2. NFS UID type definition mismatch allows unauthorized root access. 3. ICMP redirect messages may be spoofed, causing network connections to be dropped. PLATFORM: All Sun 3 and Sun 4 architectures running SunOS versions 4.1, 4.1.1, or 4.1.2 DAMAGE: Unauthorized root access. Denial of service. SOLUTION: Apply Sun Patches 100376-04, 100173-08, and 100567-02. __________________________________________________________________________ Critical Facts about New SunOS Security Patches This bulletin supersedes CIAC Bulletin B-41. CIAC has received information from Sun Microsystems regarding three new security patches for SunOS versions 4.1, 4.1.1, and 4.1.2 on all Sun 3 and Sun 4 architectures. These patches close vulnerabilities which permit both unauthorized root access and denial of network service attacks. The new patches are all upgraded versions of previous Sun patches, fixing both newly discovered vulnerabilities and vulnerabilities not completely removed by the previous versions. CIAC recommends all three patches be applied, even if previous versions have already been installed. Note also that, as these patches require regeneration of the system kernel, you may wish to install all three patches at one time. The patches are available both through your local Sun Answer Center and anonymous ftp. In the U.S., ftp to ftp.uu.net and retrieve the patches from the directory ~ftp/systems/sun/sun-dist. In Europe, ftp to mcsun.eu.net and retrieve the patches from the ~ftp/sun/fixes directory. The patches are contained in the compressed tarfiles indicated below and have the indicated checksums (obtained using the SunOS "sum" command). Please note that Sun Microsystems occasionally updates patch files, resulting in a changed checksum. If you find that the checksum differs from those listed below, please contact Sun Microsystems or CIAC for verification before using the patch. Patch Filename Description Checksum --------------- ----------------------------------------- --------- 100376-04.tar.Z Sparc integer multiplication and division 12884 100 100173-08.tar.Z NFS Jumbo, UID truncation 32716 562 100567-02.tar.Z ICMP message spoofing 23118 13 To install the patches on your system, follow the instructions contained in the README files which accompany each patch. For additional information or assistance, please contact CIAC at (510) 422-8193 / FTS or send e-mail to ciac@llnl.gov. FAX messages to (510) 423-8002 / FTS. Previous CIAC bulletins and other information are available via anonymous ftp from irbis.llnl.gov (ip address 128.115.19.60). CIAC would like to thank both Gene Spafford of Purdue University and Ken Pon of Sun Microsystems for their help with this bulletin. PLEASE NOTE: Many users outside of the DOE and ESnet computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Some of the other teams include the NASA NSI response team, DARPA's CERT/CC, NAVCIRT, and the Air Force response team. Your agency's team will coordinate with CIAC. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the University of California, and shall not be used for advertising or product endorsement purposes. _______________________________________________________ The Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ Information Bulletin Summary of SunOS Security Patches July 31, 1992 1400 PDT Number C-29 CIAC has compiled a list of all security related patches currently available from Sun Microsystems. The patches have been grouped by SunOS version and are detailed below. CIAC recommends the installation of any applicable patches that either are not currently present on your system or are present in the form of an older version of the patch. The patches are available both through your local Sun Answer Center and anonymous ftp. In the U.S., ftp to ftp.uu.net and retrieve the patches from the directory ~ftp/systems/sun/sun-dist. In Europe, ftp to mcsun.eu.net and retrieve the patches from the ~ftp/sun/fixes directory. The patches are contained in compressed tarfiles with filenames based on the ID number of the patch (e.g. patch 100085-03 is contained in the file 100085-03.tar.Z), and must be retrieved using ftp's binary transfer mode. After obtaining the patches, compute the checksum of each compressed tarfile and compare with the values indicated below. For example, the command "sum 100085-03.tar.Z" should produce the value 44177 740. Please note that Sun Microsystems occasionally updates patch files, resulting in a changed checksum. If you should find a checksum that differs from those listed below, please contact Sun Microsystems or CIAC for verification before using the patch. Finally, the patches must be extracted from the compressed tarfiles using the commands uncompress and tar (e.g. to extract patch 100085-03, execute the commands "uncompress 100085-03.tar.Z" and "tar -xvf 100085-03.tar"). As multiple patches may affect the same files, it is recommended that patches be installed chronologically by revision date, with the exception of patches for which an explicit order is specified. To install a patch on your system, follow the instructions contained in the README file which accompanies the patch. SunOS 4.0.1 and 4.0.2 Patch ID Last Revised Checksum Description --------- ------------ --------- ------------------------------------- 100085-03 5-Sep-90 44177 740 selection_svc and rpc can be used to view system files without login permission SunOS 4.0.2i Patch ID Last Revised Checksum Description --------- ------------ --------- ------------------------------------- 100108-01 22-Aug-90 50309 146 sendmail can be coaxed into writing a file not owned by the sender SunOS 4.0.3 and 4.0.3c Patch ID Last Revised Checksum Description --------- ------------ --------- ------------------------------------- 100224-02 15-Jan-90 39010 223 mail and rmail can invoke root and uucp shells 100100-01 30-Jul-90 43821 588 sendmail permits users to run programs with root's group privileges 100101-02 7-Aug-90 42872 34 ptrace security hole 100085-03 5-Sep-90 44177 740 selection_svc and rpc can be used to view system files without login permission 100184-02 14-Dec-90 06627 33 OpenWindows 2.0 sv_xv_sel_svc and rpc permit access to system files 100125-05 8-Jul-91 41964 164 telnet permits password capture 100383-04 5-Feb-92 42306 113 rdist can be forced to create setuid root programs SunOS 4.1 Patch ID Last Revised Checksum Description --------- ------------ --------- ------------------------------------- 100224-02 15-Jan-90 39010 223 mail and rmail can invoke root and uucp shells 100101-02 7-Aug-90 42872 34 ptrace security hole 100085-03 5-Sep-90 44177 740 selection_svc and rpc can be used to view system files without login permission 100184-02 14-Dec-90 06627 33 OpenWindows 2.0 sv_xv_sel_svc and rpc permit access to system files 100187-01 15-Dec-90 27724 139 Console input and output can be redirected 100251-01 25-Mar-91 44264 32 expreserve race condition 100121-08 1-Apr-91 61464 287 NFS jumbo patch 100201-04 3-Jul-91 24358 169 C2 jumbo patch 100125-05 8-Jul-91 41964 164 telnet permits password capture 100103-10 30-Sep-91 26292 7 Many files distributed with incorrect permissions 100296-02 16-Oct-91 30606 23 rpc.mountd exports filesystems incorrectly 100383-04 5-Feb-92 42306 113 rdist can be forced to create setuid root programs 100305-07 3-Mar-92 25894 283 The lp daemon can delete system files 100173-08 7-May-92 32716 562 NFS jumbo patch 100377-04 14-May-92 14692 311 sendmail security holes 100630-01 18-May-92 36269 39 Environment variables can be used to exploit login and su 100482-02 20-May-92 53416 284 ypserv and ypxfrd will send NIS maps to anyone 100567-02 13-Jul-92 23118 13 ICMP redirect messages can be used to make a host drop network connections 100376-04 16-Jul-92 12884 100 Integer division on Sparc can allow root access SunOS 4.1_PSR_A Patch ID Last Revised Checksum Description --------- ------------ --------- ------------------------------------- 100224-02 15-Jan-90 39010 223 mail and rmail can invoke root and uucp shells 100184-02 14-Dec-90 06627 33 OpenWindows 2.0 sv_xv_sel_svc and rpc permit access to system files 100187-01 15-Dec-90 27724 139 Console input and output can be redirected 100201-04 3-Jul-91 24358 169 C2 jumbo patch 100296-02 16-Oct-91 30606 23 rpc.mountd exports filesystems incorrectly 100383-04 5-Feb-92 42306 113 rdist can be forced to create setuid root programs 100305-07 3-Mar-92 25894 283 The lp daemon can delete system files 100377-04 14-May-92 14692 311 sendmail security holes 100630-01 18-May-92 36269 39 Environment variables can be used to exploit login and su SunOS 4.1.1 Patch ID Last Revised Checksum Description --------- ------------ --------- ------------------------------------- 100224-02 15-Jan-90 39010 223 mail and rmail can invoke root and uucp shells 100085-03 5-Sep-90 44177 740 selection_svc and rpc can be used to view system files without login permission 100184-02 14-Dec-90 06627 33 OpenWindows 2.0 sv_xv_sel_svc and rpc permit access to system files 100251-01 25-Mar-91 44264 32 expreserve race condition 100201-04 3-Jul-91 24358 169 C2 jumbo patch 100125-05 8-Jul-91 41964 164 telnet permits password capture 100296-02 16-Oct-91 30606 23 rpc.mountd exports filesystems incorrectly 100103-10 30-Sep-91 26292 7 Many files distributed with incorrect permissions 100424-01 12-Nov-91 63070 50 NFS with fsirand file handle guessing problems Note: should only be applied with patch 100173-08 Note: incompatible with Online: DiskSuite and Backup: Copilot 100448-01 10-Dec-91 02672 5 OpenWindows 3.0 loadmodule security hole 100387-02 3-Feb-92 07868 4400 C2 bug fixes and enhancements, Basic Security Module Note: incompatible with patch 100201-04 100383-04 5-Feb-92 42306 113 rdist can be forced to create setuid root programs 100478-01 14-Feb-92 64588 58 OpenWindows 3.0 xlock can crash, leaving system open 100188-02 28-Feb-92 52332 132 TIOCCONS and pty security holes 100305-07 3-Mar-92 25894 283 The lp daemon can delete system files 100173-08 7-May-92 32716 562 NFS jumbo patch Note: incompatible with Online: DiskSuite and Backup: Copilot 100377-04 14-May-92 14692 311 sendmail security holes 100630-01 18-May-92 36269 39 Environment variables can be used to exploit login and su 100482-02 20-May-92 53416 284 ypserv and ypxfrd will send NIS maps to anyone 100633-01 22-May-92 43774 20 Environment variables can be used to exploit login and su when using Sun's ARM product 100567-02 13-Jul-92 23118 13 ICMP redirect messages can be used to make a host drop network connections 100376-04 16-Jul-92 12884 100 Integer division on Sparc can allow root access SunOS 4.1.2 Patch ID Last Revised Checksum Description --------- ------------ --------- ------------------------------------- 100184-02 14-Dec-90 06627 33 OpenWindows 2.0 sv_xv_sel_svc and rpc permit access to system files 100296-02 16-Oct-91 30606 23 rpc.mountd exports filesystems incorrectly 100448-01 10-Dec-91 02672 5 OpenWindows 3.0 loadmodule security hole 100383-04 5-Feb-92 42306 113 rdist can be forced to create setuid root programs 100478-01 14-Feb-92 64588 58 OpenWindows 3.0 xlock can crash, leaving system open 100188-02 28-Feb-92 52332 132 TIOCCONS and pty security holes 100564-01 1-Apr-92 29774 415 C2 jumbo patch 100305-07 3-Mar-92 25894 283 The lp daemon can delete system files 100173-08 7-May-92 32716 562 NFS jumbo patch 100377-04 14-May-92 14692 311 sendmail security holes 100630-01 18-May-92 36269 39 Environment variables can be used to exploit login and su 100482-02 20-May-92 53416 284 ypserv and ypxfrd will send NIS maps to anyone 100633-01 22-May-92 43774 20 Environment variables can be used to exploit login and su when using Sun's ARM product 100567-02 13-Jul-92 23118 13 ICMP redirect messages can be used to make a host drop network connections 100376-04 16-Jul-92 12884 100 Integer division on Sparc can allow root access Note: sun4m architectures require patch 100542-04 For additional information or assistance, please contact CIAC: Voice: (510) 422-8193 / FTS E-mail: ciac@llnl.gov FAX: (510) 423-8002 / FTS. Previous CIAC bulletins and other information are available via anonymous ftp from irbis.llnl.gov (ip address 128.115.19.60). PLEASE NOTE: Many users outside of the DOE and ESnet computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Some of the other teams include the NASA NSI response team, DARPA's CERT/CC, NAVCIRT, and the Air Force response team. Your agency's team will coordinate with CIAC. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the University of California, and shall not be used for advertising or product endorsement purposes. _____________________________________________________ The Computer Incident Advisory Capability ___ __ __ _ ___ / | / \ / \___ __|__ /___\ \___ _____________________________________________________ INFORMATION BULLETIN VAX/VMS Security Vulnerability in MONITOR August 24, 1992, 1200 PDT Number C-30 ________________________________________________________________________ PROBLEM: The MONITOR utility on VMS versions 5.0 thru 5.4-2 can be used to obtain unauthorized privileges. PLATFORM: VAX systems running the VMS operating system. DAMAGE: An unprivileged user can obtain all privileges. SOLUTION: Upgrade to VMS version 5.4-3 (or higher); alternatively disable or restrict access to MONITOR. ________________________________________________________________________ Critical Information About MONITOR Vulnerability CIAC is forwarding Digital Equipment Corporation's Software Security Response Team's (SSRT) advisory regarding this problem. While CIAC believes the information contained to be accurate, SSRT is fully responsible for its contents. DEC requires its advisory be redistributed intact. CIAC and DEC recommend upgrading VMS to the latest version. However, if you are unable to upgrade, there is a workaround described in the following DEC Advisory: =============================================================================== SSRT-0200 PROBLEM: Potential Security Vulnerability Identified in MONITOR SOURCE: Digital Equipment Corporation AUTHOR: Software Security Response Team - U.S. Colorado Springs USA PRODUCT: VMS Symptoms Identified On: VMS, Versions 5.0, 5.0-1, 5.0-2, 5.1, 5.1-B, 5.1-1, 5.1-2, 5.2, 5.2-1, 5.3, 5.3-1, 5.3-2, 5.4, 5.4-1, 5.4-2 ******************************************************* SOLUTION: This problem is not present in VMS V5.4-3 (released in October 1991) through VMS V5.5-1 (released in July, 1992). ******************************************************* Copyright (c) Digital Equipment Corporation, 1992 All Rights Reserved. Published Rights Reserved Under The Copyright Laws Of The United States. ------------------------------------------------------------------------------- PROBLEM/IMPACT: ------------------------------------------------------------------------------- Unauthorized privileges may be expanded to authorized users of a system under certain conditions, via the MONITOR utility. Should a system be compromised through unauthorized access, there is a risk of potential damage to a system environment. This problem will not permit unauthorized access entry, as individuals attempting to gain unauthorized access will continue to be denied through the standard VMS security mechanisms. ------------------------------------------------------------------------------- SOLUTION: ------------------------------------------------------------------------------- This potential vulnerability does not exist in VMS V5.4-3 (released in October 1991) and later versions of VMS through V5.5-1. Digital strongly recommends that you upgrade to a minimum of VMS V5.4-3, and further, to the latest release of VMS V5.5-1 (released in July, 1992). ------------------------------------------------------------------------------- INFORMATION: ------------------------------------------------------------------------------- If you cannot upgrade at this time, Digital recommends that you implement a workaround (examples attached below) to avoid any potential vulnerability. As always, Digital recommends that you periodically review your system management and security procedures. Digital will continue to review and enhance the security features of its products and work with customers to maintain and improve the security and integrity of their systems. ------------------------------------------------------------------------------- WORKAROUND ------------------------------------------------------------------------------- A suggested workaround would be to remove the installed image SYS$SHARE:SPISHR.EXE via VMS INSTALL and/or restrict the use of the MONITOR utility to "privileged" system administrators. Below are the examples of doing both. [1] To disable the MONITOR utility the image SYS$SHARE:SPISHR.EXE should be deinstalled from a privileged account. For cluster configurations; --------------------------- $ MC SYSMAN SYSMAN> SET ENVIRONMENT/CLUSTER SYSMAN> DO INSTALL REMOVE SYS$SHARE:SPISHR.EXE SYSMAN> DO RENAME SYS$SHARE:SPISHR.EXE SPISHR.HOLD SYSMAN> EXIT For non-VAXcluster configurations; --------------------------------- $ INSTALL INSTALL> REMOVE SYS$SHARE:SPISHR.EXE INSTALL> EXIT $ RENAME SYS$SHARE:SPISHR.EXE SPISHR.HOLD [2] If you wish to restrict access to the MONITOR command so that only a limited number of authorized (or privileged) persons are granted access to the utility, one method might be to issue the following commands from a privileged account; For cluster configurations; --------------------------- $ MC SYSMAN SYSMAN> SET ENVIRONMENT/CLUSTER SYSMAN> DO INSTALL REMOVE SYS$SHARE:SPISHR.EXE SYSMAN> DO SET FILE/ACL=(ID=*,ACCESS=NONE) SYS$SHARE:SPISHR.EXE SYSMAN> DO SET FILE/ACL=(ID=SYSTEM,ACCESS=READ+EXECUTE) SYS$SHARE:SPISHR.EXE SYSMAN> DO INSTALL ADD SYS$SHARE:SPISHR.EXE/OPEN/HEADER/SHARE/PROTECT SYSMAN> EXIT $ THIS WILL IMPACT the MONITOR UTILITY FOR REMOTE MONITORING. LOCAL USE OF MONITOR WILL CONTINUE TO WORK FOR PERSONS HOLDING THE ID's GRANTED ACL ACCESS. see additional note(s) below For non-VAXcluster configurations; ---------------------------------- $ INSTALL INSTALL> REMOVE SYS$SHARE:SPISHR.EXE INSTALL> EXIT $ SET FILE /ACL=(ID=*,ACCESS=NONE) SYS$SHARE:SPISHR.EXE $ SET FILE /ACL=(ID=SYSTEM,ACCESS=READ+EXECUTE) SYS$SHARE:SPISHR.EXE $ INSTALL INSTALL> ADD SYS$SHARE:SPISHR.EXE/OPEN/HEADER/SHARE/PROTECT INSTALL> EXIT $ NOTE in the above examples: The "SET FILE /ACL" line should be repeated for all accounts that are required/allowed to use the DCL MONITOR command. The ID -SYSTEM- should be replaced with valid user ID's that are to be associated with accounts you wish to grant access to. End of DEC Advisory =============================================================================== If you require additional assistance or wish to report a vulnerability, call CIAC at (510) 422-8193/FTS or send e-mail to ciac@llnl.gov. FAX messages to: (510) 423-8002/FTS. For emergencies only, call 1-800-SKYPAGE and enter PIN number 855-0070 (primary) or 855-0074 (secondary). The CIAC Bulletin Board, Felicia, can be accessed at 1200 or 2400 baud at (510) 423-4753/FTS and 9600 baud at (510) 423-3331/FTS. Previous CIAC bulletins and other information is available via anonymous ftp from irbis.llnl.gov (ip address 128.115.19.60). CIAC wishes to thank Rich Boren of DEC's SSRT for assistance and the advisory used in this bulletin. PLEASE NOTE: Many users outside of the DOE and ESnet computing communities receive CIAC bulletins. If you are not part of these communities, please contact your agency's response team to report incidents. Some of the other teams include the NASA NSI response team, DARPA's CERT/CC, NAVCIRT, and the Air Force response team. Your agency's team will coordinate with CIAC. This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government nor the University of California, and shall not be used for advertising or product endorsement purposes.