
**********************************************************************
 
DDN Security Bulletin 02         DCA DDN Defense Communications System
05 Oct 89               Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155
 
                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN
 
The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [26.0.0.73 or
10.0.0.51] using login="anonymous" and password="guest".  The bulletin
pathname is SCC:DDN-SECURITY-nn (where "nn" is the bulletin number).
 
**********************************************************************
 
   COLUMBUS DAY / OCTOBER 12TH / FRIDAY THE 13TH / DATACRIME VIRUS
 
1.  Recently, there has been  considerable attention given to a family
of MS/DOS-PC  viruses  with many  names:   Columbus Day,  October 12th
(later redesignated  October 13th),  Friday the  13th, and  DataCrime.
According to the Computer Virus Industry Association, there have  been
only  SEVEN  confirmed  U. S.  "sightings"  to  date.   Based on this,
there may be only a few dozen sites affected.
 
2.  Normally the SCC  would not  be involved  with a personal computer
virus incident (unless it was propagated via the DDN).  However,  this
virus  has  received  extensive  media  coverage,  necessitating a DDN
Security Bulletin to answer some commonly asked questions.
 
+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +
 
Q:  What is known about this Columbus Day/DataCrime virus?
 
A:  There  are  several  variants  of  DataCrime.  They are designated
"1168", "1280", and "DataCrime II" (or "1514"); this naming convention
is based on  the number of  bytes each added to the .COM  files it has
infected.  DataCrime II infects both .EXE and .COM files.
 
 
Q:  How does DataCrime spread?
 
A:  The DataCrime Viruses are designed to infect via diskette sharing.
There is no network component  (unlike the infamous  November Internet
Worm),  therefore they  CANNOT traverse the  DDN unassisted.  The only
way a DataCrime virus can be spread through a network is by FTP'ing an
infected file into a PC and running it.
 
 
Q:  What is the result?
 
A:  On or after Friday, 13 October 1989, these software timebombs will
reformat cylinder 0 of any  infected hard disk (drive C:)  and display
the message,  "DATACRIME VIRUS RELEASED: 1 MARCH 1989".   The infected
PC cannot boot from drive C:, and all data on it is unreachable.
 
 
Q:  How can DataCrime (and other viruses) be stopped?
 
A:  The  National  Institute of  Standards  and Technology  (NIST) has
recently  issued  guidelines  for  controlling  malicious  software in
various computer  environments, including  PCs and  networks.  The SCC
has obtained  an electronic copy of  NIST Special Publication 500-166,
"Computer Viruses and Related Threats:  A Management Guide" by John P.
Wack  and  Lisa J. Carnahan.   It may be obtained via FTP  (or Kermit)
from NIC.DDN.MIL [26.0.0.73 or 10.0.0.51] using login="anonymous" and
password="guest".  The pathname is SCC:NIST-001.
 
**********************************************************************

**********************************************************************
DDN Security Bulletin 06         DCA DDN Defense Communications System
1 Nov 89                Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [26.0.0.73 or
10.0.0.51] using login="anonymous" and password="guest".  The bulletin
pathname is SCC:DDN-SECURITY-nn (where "nn" is the bulletin number).

**********************************************************************

                       SUN RCP VULNERABILITY
 
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!   The following important advisory was issued by the Computer         !
!   Emergency Response Team (CERT) and is being relayed via the Defense !
!   Communications Agency's Security Coordination Center distribution   !
!   system as a means of providing DDN subscribers with useful          !
!   security information.                                               !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +


			    CERT Advisory

			   October 26, 1989

			Sun RCP vulnerability

A problem has been discovered in the SunOS 4.0.x rcp.  If exploited,
this problem can allow users of other trusted machines to execute
root-privilege commands on a Sun via rcp.

This affects only SunOS 4.0.x systems; 3.5 systems are not affected.

A Sun running 4.0.x rcp can be exploited by any other trusted host
listed in /etc/hosts.equiv or /.rhosts.  Note that the other machine
exploiting this hole does not have to be running Unix; this
vulnerability can be exploited by a PC running PC/NFS, for example.

This bug will be fixed by Sun in version 4.1 (Sun Bug number 1017314),
but for now the following workaround is suggested by Sun:

Change the 'nobody' /etc/passwd file entry from

nobody:*:-2:-2::/:

to

nobody:*:32767:32767:Mismatched NFS ID's:/nonexistant:/nosuchshell


If you need further information about this problem, please contact
CERT by electronic mail or phone.


J. Paul Holbrook
Computer Emergency Response Team (CERT)
Carnegie Mellon University
Software Engineering Institute

Internet: <cert@SEI.CMU.EDU>
(412) 268-7090 (24 hour hotline)
***********************************************************************
DDN Security Bulletin 90-04      DCA DDN Defense Communications System
2 Mar 90                Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [26.0.0.73 or
10.0.0.51] using login="anonymous" and password="guest".  The bulletin
pathname is SCC:DDN-SECURITY-yy-nn (where "yy" is the year the bulletin
is issued and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-90-01).
**********************************************************************

                  COMPUTER SYSTEM "WELCOME" BANNERS

1.  The Defense Communications Agency/Data Systems Management
Division (DDO) is in the process of fielding a patch to all
Defense Data Network (DDN) Terminal Access Controllers (TACs)
that will remove the DDN "Welcome" banners.  This is being
accomplished as a security measure for the following
principle reasons:

   a.  To terminate the identification of the system as belonging to
the DDN/MILNET, and to terminate the identification of the type of
operating system or software in use on the system.  All too often
intruders stumble by chance upon a MILNET host because the system is
identified in the banner as being "defense" and/or "For Official Use
Only".  Intruders can also use software or operating system
information from the banner to facilitate an intrusion.  Therefore,
it is best not to identify a system at all in its banner.

   b.  A court recently threw out a suit against a computer system
intruder because the logon prompt was preceded with "Welcome to...".


2.  Request Host Administrators and other addressees, in favor of
tighter security, take an active role in getting their
commands/units/organizations to change existing logon banners to
make certain that the identity of their data systems is not displayed,
and to halt the use of "Welcome".
***********************************************************************
DDN Security Bulletin 90-08      DCA DDN Defense Communications System
7 May 90                Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.67.67.20]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yy-nn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-90-01).
**********************************************************************

                     UNISYS U5000 /etc/passwd PROBLEM

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

CA-90-03                       CERT Advisory
                                May 7, 1990
                    Unisys U5000 /etc/passwd problem


The CERT/CC has recently verified several reports of unauthorized access 
to Internet connected Unisys systems.  The intruder(s) gained access to 
these systems by logging into vendor supplied default accounts; accounts 
that had not been given passwords by the systems' owners.  

Gary Garb, Corporate Computer Security Officer for Unisys Corporation, 
states: 

 "The Unisys U5000 series UNIX systems are delivered with a number of
 system logins.  The logins are NOT password protected when the
 customer receives the system.  Unless the customer secures these logins,
 the system is vulnerable to unauthorized access."

 "A complete list of these logins can be found in the /etc/passwd file.
 Each login is described by one record in /etc/passwd which contains a 
 number of fields separated by colons.  The second field normally would
 contain the encrypted password.  The system logins will initially have
 a null second field (indicated by two adjacent colons) in their descriptive
 records in /etc/passwd."

 "The U5000/80/85/90/95 System V Administration Guide, Volume 1 (UP13679)
 begins with a chapter on "System Identification and Security".  On page 1-2
 it states, "All logins should have passwords ... Logins that are not needed
 should be either removed (by deleting from /etc/passwd) or blocked (by 
 locking the login as described in the section "Locking Unused Logins" on
 page 1-8).  The Guide contains complete instructions on controlling logins
 and passwords."

 "It is the user's (system administrator's) responsibility to thoroughly
 read the Guide and to ensure the security of the system.  *Securing the 
 login entries should be of the highest priority and should be accomplished
 before anyone else has access to the system.*"

The CERT/CC urges administrators of Unisys systems, as well as administrators 
of systems provided by other vendors,  to check their systems and insure all 
accounts are protected by passwords; passwords that are different from the 
default passwords provided by the vendor. 

Questions regarding the security aspects of Unisys systems should be directed 
to:
   Gary Garb, Corporate Security Officer
   Unisys Corporation
   (215) 986-4038

-------
Dan Farmer
Computer Emergency Response Team (CERT)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Internet: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline: CERT personnel answer
           7:30a.m.-6:00p.m. EST, on call for
           emergencies other hours.

Past advisories and other information are available for anonymous ftp
From cert.sei.cmu.edu (128.237.253.50).


***********************************************************************
DDN Security Bulletin 9012      DCA DDN Defense Communications System
29 Oct 90               Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.67.67.20]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9001).
***********************************************************************

                        VMS SECURITY PROBLEM

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

CA-90:07                       CERT Advisory
                              October 25, 1990
                          VMS ANALYZE/PROCESS_DUMP

-------------------------------------------------------------------------

The CERT/CC has received a report of a security vulnerability which
exists under specific conditions in Digital VMS Software  (Versions 4.0
to 5.4).  The DESCRIPTION, IMPACT, SOLUTION, and CONTACT INFORMATION
sections below have been provided to the CERT/CC by the Digital Equipment
Corporation.
 
-------------------------------------------------------------------------
DESCRIPTION:
 
Non-privileged users can acquire system privileges through
the ANALYZE/PROCESS_DUMP routine.
 
 
IMPACT:
 
Non-privileged users who gain increased privileges might deliberately
or inadvertently affect the integrity of system information and/or
affect the integrity of the computing resource.
 
SOLUTION:
 
Digital is currently working on a permanent solution to this 
problem.  While a permanent fix is being completed, Digital 
recommends that the following actions be taken on every VMS 
system (this includes all nodes in a VAXcluster system).
 
                   
After taking the following actions, non-privileged users will not be able 
to use the ANALYZE/PROCESS_DUMP command.
 
1.  Log into the system account.
 
2.  $ SET PROC/PRIV=ALL
 
3.  a)  For VMS versions prior to V5.0,
 
        Modify SYS$MANAGER:SYSTARTUP.COM to include the following lines:
 
		 $ SET NOON
		 $ MCR INSTALL ANALIMDMP.EXE/DELETE
 
	as the first two commands in this file.
 
    b)  For VMS versions V5.0 and later,
 
        Modify SYS$MANAGER:SYSTARTUP_V5.COM to include the following 
	lines:
 
		 $ SET NOON
		 $ MCR INSTALL ANALIMDMP.EXE/DELETE
 
	as the first two commands in this file.
 
    c)  For MicroVMS systems,
 
        The image ANALIMDMP.EXE is not installed by default, but 
        SYSTARTUP.COM contains a suggestion for installing the image if 
	you have multiple users on your system.  You must ensure that 
	this image is not installed by SYSTARTUP.COM.  You can  use the
        following command to verify that the image is not  installed:
 
		  $ MCR INSTALL ANALIMDMP/LIST
	
4.  $ MCR INSTALL ANALIMDMP/DELETE
 
    This command removes the installed image from the active system.
 
5.  (Optional) Restart your systems and verify that the image is not 
    installed using the following command:
 
		  $ MCR INSTALL ANALIMDMP/LIST
 
     You should receive a message similar to the following:
 
	%INSTALL-W-FAIL, failed to LIST entry for ANALIMDMP.EXE
	-INSTALL-E-NOKFEFND, Known File Entry not found
 
 
CONTACT INFORMATION:
 
For further questions, please contact your Digital Customer Support     
Center.
 
-------------------------------------------------------------------------

The CERT/CC thanks Digital for the information above, and thanks Clive
Walmsley, Royal Signal and Radar Establishment, Malvern England, for
reporting this problem to CERT/CC.
 
-------------------------------------------------------------------------
 
Dan Farmer
Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
 
Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline: CERT personnel answer
           7:30a.m.-6:00p.m. EST, on call for
           emergencies other hours.
 
Past advisories and other information are available for anonymous ftp
from cert.sei.cmu.edu (128.237.253.5).

 



***********************************************************************
DDN Security Bulletin 9102       DCA DDN Defense Communications System
25 Feb 91               Published by: DDN Security Coordination Center
OBSOLETES DDN Sec. Bull. 9101        (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.67.67.20]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9001).
**********************************************************************

                   REVISED SunOS /bin/mail Vulnerability


+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +


CA-91:01a                       CERT Advisory
                             February 22,  1991
                   REVISED SunOS /bin/mail Vulnerability

-------------------------------------------------------------------------

		 *** THIS IS A REVISED CERT ADVISORY ***

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received the following information from Sun Microsystems, Inc. (Sun).
Sun has given the CERT/CC permission to distribute their Security
Bulletin. It contains information regarding a fix for a vulnerability
in SunOS 4.0.3, SunOS 4.1 and SunOS 4.1.1.

An important piece of information was missing from the Sun Security
Bulletin #00105 which was included in the CA-91:01 CERT Advisory on
this same subject.  After the old /bin/mail has been renamed, it is
important to remove the setuid root bit.  Sun also suggests that the
protection bits on the new /bin/mail to be set to 4111 instead of 4755.

The CERT/CC advises that the /bin/mail.old file be removed once the new
/bin/mail is in place and verified that it is functioning correctly.

This is from the original Sun Security Bulletin #00105:

	   AS ROOT:

	   # mv /bin/mail to /bin/mail.old
	   # cp $arch/$os/mail to /bin/mail
 	   (where $arch is either sun3 sun4 sun4c or sun3x)
 	   (and where $os is either 4.0.3 4.1 or 4.1.1)
 	   ( change the permissions for the newly installed mail)
	   # chmod 4755 /bin/mail


In CERT's opinion, the CERT Advisory should have the following information.

	   AS ROOT:

	   # mv /bin/mail to /bin/mail.old
  new->    # chmod 400 /bin/mail.old
	   # cp $arch/$os/mail to /bin/mail
 	   (where $arch is either sun3 sun4 sun4c or sun3x)
 	   (and where $os is either 4.0.3 4.1 or 4.1.1)
 	   ( change the permissions for the newly installed mail)
updated -> # chmod 4111 /bin/mail

The complete Sun Security Bulletin #00105 is being resent including the
CERT/CC changes.

For more information, please contact Sun Microsystems at 1-800-USA-4SUN.

-------------------------------------------------------------------------

SUN MICROSYSTEMS SECURITY BULLETIN:
#00105

This information is only to be used for the purpose of alerting
customers to problems. Any other use or re-broadcast of this
information without the express written consent of Sun Microsystems
shall be prohibited.

Sun expressly disclaims all liability for any misuse of this information
by any third party.
============================================================================

All of these patches are available through your local Sun answer centers
worldwide. As well as through anonymous ftp to ftp.uu.net in the
~ftp/sun-dist directory.

Please refer to the Sun BugID and PatchID when requesting patches from Sun
answer centers.
 
NO README information will be posted in the patch on UUNET. Please refer
the the information below for patch installation instructions.
============================================================================
 
Sun Bug ID  : 1047340
Synopsis    : /bin/mail can be caused to invoke a root shell if given the
              (im)proper arguments.
Sun Patch ID: 100224-01
Checksum of compressed tarfile 100224-01.tar.Z = 64102   109
 
============================================================================

Patch-ID#  100224-01
Keywords: mail, delivery, /bin/mail, 4.1, sendmail
Synopsis: SunOS 4.1.1, 4.1,  4.0.3: program "mail" problem in delivering
          mail + security enhancement
Date: 15 Jan 1990
 
SunOS release: 4.0.3 4.1 4.1.1

Topic:  /bin/mail delivering fix
 
BugId's fixed with this patch: 1045636 1047340

Architectures for which this patch is available: sun3, sun3x, sun4, sun4c,
sun4/490_4.1_PSR_A.

Patches which may conflict with this patch: 100161-01. This patch obsoletes
					    patch 100161-01 since this patch
					    incorporates 100161-01 fixes plus
					    the new fixes.
Obsoleted by: SysV Release 4

Problem Description:

Bug ID: 1045636

 /bin/mail is the local delivery agent for sendmail.  In
some particular instance, /bin/mail parse its argument incorrectly
and therefore, mail are being drop into the bit bucket...

If you have users that has "f" has the second character, you might want
to try the following: (substitute "af" with anyuser with "f" as second
character)

From any machine except mailhost:

/bin/lib/sendmail -t -v <<END
From: anyuser
to: anyuser
Subject: test
Cc: af          <-- substitute any username with second character as "f"
test

END

When the mail arrived on mailhost, sendmail process will invoke
/bin/mail with the following argument "/bin/mail -r anyuser -d af
anyuser".  Now you are in trouble.  The following are different
scenarios for /bin/mail.

1) /bin/mail -r anyuser -d af  <mailmessages            worked fine
2) /bin/mail -r anyuser -d anyone af ... <mailmessages  worked fine
3) /bin/mail -r anyuser -d af anyone ... <mailmessages  !!error!!

    in case (3), /bin/mail thinks that you want to read mail instead of
    delivering mail.  Therefore, mail messages is lost.

 
BugID: 1047340

/bin/mail can be caused to invoke a root shell if given the
        (im)proper arguments.  

INSTALL:

AS ROOT:
 
# mv /bin/mail to /bin/mail.old
# chmod 400 /bin/mail.old
# cp $arch/$os/mail to /bin/mail
 (where $arch is either sun3 sun4 sun4c or sun3x)
 (and where $os is either 4.0.3 4.1 or 4.1.1)
 ( change the permissions for the newly installed mail)
# chmod 4111 /bin/mail

-------------------------------------------------------------------------
Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:
           CERT personnel answer 7:30a.m.-6:00p.m. EST.
           On call for emergencies during other hours.

Past advisories and other computer security related information are available
for anonymous ftp from the cert.sei.cmu.edu (128.237.253.5) system.

 
***********************************************************************
DDN Security Bulletin 9106       DCA DDN Defense Communications System
1 May 91                Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.67.67.20]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9001).
**********************************************************************

                    DEC Ultrix chroot Vulnerability

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +


CA-91:05                        CERT Advisory
                                 May 1, 1991
                        DEC Ultrix chroot Vulnerability

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning a vulnerability in Digital Equipment 
Corporation's (DEC) Ultrix operating system versions 4.0 and 4.1 for all
DEC architectures.  The vulnerability has been fixed in version 4.2 which 
will be shipped beginning in late May.  DEC has also provided a suggested 
fix for versions 4.0 and 4.1.
  
---------------------------------------------------------------------------
I.   DESCRIPTION:
     By default, /usr/bin/chroot is improperly installed in Ultrix 
     versions 4.0 and 4.1.
     
II.  IMPACT:
     System users can gain unauthorized privileges.

III. SOLUTION:
     Change the permission on the file /usr/bin/chroot.

     # chmod 700 /usr/bin/chroot    

---------------------------------------------------------------------------
Our thanks to Eric R. Jorgensen and Brian Ellis of UnixOps / Distributed 
Computing Services at the University of Colorado, Boulder, for bringing this 
problem to our attention.  The CERT/CC would also like to thank Digital for 
their response to this vulnerability.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC via
telephone or e-mail.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:
           CERT/CC personnel answer 7:30a.m.-6:00p.m. EST,
           on call for emergencies during other hours.

Past advisories and other computer security related information are available
for anonymous ftp from the cert.sei.cmu.edu (128.237.253.5) system.
Organization:  National Institute of Standards and Technology (NIST)
Sub-Organization:  National Computer Systems Laboratory
 

***********************************************************************
DDN Security Bulletin 9111      DCA DDN Defense Communications System
15 Aug 91               Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.67.67.20]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9001).
**********************************************************************

                  ULTRIX LAT/Telnet Gateway Vulnerability

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

CA-91:11                        CERT Advisory
                               August 14, 1991
                  ULTRIX LAT/Telnet Gateway Vulnerability

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning a vulnerability in LAT/Telnet gateway
software in Digital Equipment Corporation's (DEC) ULTRIX versions 4.1 
and 4.2 on all architectures.  Information regarding the exploitation
of this vulnerability has been publicly disclosed so we recommend
taking immediate action.  Until you are able to apply the patch we
recommend that sites disable the LAT/telnet service.  

DEC has made a patch available which consists of new /usr/ucb/telnet
binaries.

The patch is available through DEC's Customer Support Centers.  Sites
within the USA should call 1-800-525-7100.  Sites in Europe and elsewhere
should contact DEC through their normal channels.

---------------------------------------------------------------------------

I.   DESCRIPTION:

     A vulnerability exists such that ULTRIX 4.1 and 4.2 systems 
     running the LAT/Telnet gateway software can allow unauthorized 
     privileged access.  Although you may not be running the LAT/Telnet
     service at this time, the CERT/CC urges all sites to install 
     the patch.  This will ease any future installation of the
     gateway software.

     The LAT/Telnet software requires special installation and is
     NOT part of the default ULTRIX configuration.

II.  IMPACT:

     Anyone who can access a terminal or modem connected to
     the LAT server running the LAT/Telnet service can gain 
     unauthorized root privileges.

III. SOLUTION:
        
     Obtain the appropriate version of the patch kit for your 
     system architecture from your DEC Customer Support Center,
     and install according to the accompanying instructions.

---------------------------------------------------------------------------
The CERT/CC would like to thank George Michaelson of The Prentice Centre,
University of Queensland, Australia and John Annen of Davidson College for 
bringing this to our attention.  We would also like to thank DEC for their 
response to this vulnerability and CIAC for their assistance.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC via
telephone or e-mail.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:
           CERT/CC personnel answer 7:30a.m.-6:00p.m. EST,
           on call for emergencies during other hours.

Past advisories and other computer security related information are available
for anonymous ftp from the cert.sei.cmu.edu (192.88.209.5) system.
***********************************************************************
DDN Security Bulletin 9115       DCA DDN Defense Communications System
11 Sept 91              Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.67.67.20]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9001).
**********************************************************************

                   Mac/PC NCSA Telnet Vulnerability

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +




CA-91:15                        CERT Advisory
                               September 10, 1991
			Mac/PC NCSA Telnet Vulnerability

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning a vulnerability in the default
configurations of National Center for Supercomputing Applications
(NCSA) Telnet for both the Macintosh and the PC.  The vulnerability
also affects the version of NCSA Telnet with IBM 3270 terminal
emulation distributed by Clarkson University.  Two workarounds are
available that correct this problem.

NCSA has committed to changing the default configurations in future
releases.  Maintenance updates for both the Macintosh and the PC are
planned to be released in about 2 months.

NCSA provides two e-mail addresses for Telnet questions, comments,
and bug reports:

     PC Telnet		pctelnet@ncsa.uiuc.edu
     Mac Telnet		mactelnet@ncsa.uiuc.edu

---------------------------------------------------------------------------

I.   Description

     The default configuration of NCSA Telnet for both the Macintosh
     and the PC has a serious vulnerability in its implementation of
     an ftp server.

     The default configuration file enables ftp via the "ftp=yes"
     line.  However, sites should be aware that ftp is also enabled
     in the absence of any ftp statement in the configuration file.

II.  Impact

     Any Internet user can connect via ftp to a PC or Macintosh
     running the default configuration of NCSA Telnet and gain
     unauthorized read and write access to any of its files, including
     system files.

III. Solution
        
     Either disable ftp server functionality or provide password
     protection as described below.

     To disable the ftp server, add an "ftp=no" line in the
     configuration file.

     If the ftp server option is enabled (via either an "ftp=yes" line 
     in the configuration file or the absence of an ftp statement in the 
     configuration file), then the Telpass program (included with both 
     Mac and PC versions) can be used to provide password protection.  
     Telpass is used to enter usernames and encrypted passwords into a 
     password file.  The configuration file specifies the name and 
     location of the password file in the "passfile=" statement.  The 
     usage of Telpass is documented in Chapter 5 of version 2.4 of the 
     Macintosh version documentation and Chapter 7 of version 2.3 of the 
     PC version.  Note that the documentation (as well as the package 
     itself) is available by anonymous ftp from ftp.ncsa.uiuc.edu 
     (141.142.20.50).

     The instructions for enabling password protection differ between
     the Macintosh and PC versions, but in both cases they involve
     enabling the "passfile" option in the configuration file, and
     creating usernames and encrypted passwords with the Telpass
     program.  

     CERT/CC strongly urges all sites running NCSA Telnet to implement
     one of these two workarounds.

---------------------------------------------------------------------------
The CERT/CC would like to thank NCSA and Clarkson University for their
assistance.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC via
telephone or e-mail.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:
           CERT/CC personnel answer 7:30a.m.-6:00p.m. EDT,
           on call for emergencies during other hours.

Past advisories and other computer security related information are available
for anonymous ftp from the cert.sei.cmu.edu (192.88.209.5) system.

 
**************************************************************************
Security Bulletin 9119              DISA Defense Communications System
3 October 1991          Published by: DDN Security Coordination Center
                                  (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN is distributed  by the  DDN SCC  (Security
Coordination Center) under DISA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.112.36.5]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9119).
**************************************************************************

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center  distribution  system  as a  means  of        !
!     providing  DDN subscribers with useful security information.      !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
                
             DISTRIBUTION RESTRICTIONS:  PUBLIC RELEASE

Enclosed is the final draft of a CERT Advisory.  If reprinted, in part or
whole, please credit the:

      Computer Emergency Response Team/Coordination Center (CERT/CC) 

===========================================================================
CA-91:18                        CERT Advisory
                              September 27, 1991
                         Active Internet tftp Attacks

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) would
like to alert you to automated tftp probes that have been occurring over
the last few days.  These probes have attacked Internet sites throughout 
the world and in most cases the file retrieved was /etc/passwd.  However, 
other files such as /etc/rc may have been retrieved. 

The CERT/CC is working with the site(s) that were used by intruders
to launch the attacks.  We are actively contacting those sites where we
believe the retrievals were successful.  We are urging all sites to 
carefully check their system configurations concerning tftp usage.

---------------------------------------------------------------------------

I.   Description

     Unrestricted tftp access allows remote sites to retrieve
     a copy of any world-readable file.

II.  Impact

     Anyone on the Internet can use tftp to retrieve copies of a
     site's sensitive files.  For example, the recent incident
     involved retrieving /etc/passwd.  The intruder can later
     crack the password file and use the information to login
     to the accounts.  This method may provide access to the
     root account.

III. Solution
        
     A.  Sites that do not need tftp should disable it immediately by
     editing the system configuration file to comment out, or remove,
     the line for tftpd.  This file may be /etc/inetd.conf, /etc/servers,
     or another file depending on your operating system.  To cause 
     the change to be effective, it will be necessary to restart
     inetd or force inetd to read the updated configuration file.

     B.  Sites that must use tftp (for example, for booting diskless
     clients) should configure it such that the home directory is changed.  
     Example lines from /etc/inetd.conf might look like:

     ULTRIX 4.0
     tftp   dgram  udp  nowait  /etc/tftpd  tftpd -r /tftpboot

     SunOS 4.1
     tftp   dgram  udp  wait  root  /usr/etc/in.tftpd in.tftpd -s /tftpboot

     As in item A. above, inetd must be restarted or forced to read 
     the updated configuration file to make the change effective.

     C.  If your system has had tftp configured as unrestricted, the CERT/CC
     urges you to consider taking one of the steps outlined above and
     change all the passwords on your system.

---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC via
telephone or e-mail.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:
           CERT/CC personnel answer 7:30a.m.-6:00p.m. EST/EDT,
           on call for emergencies during other hours.

Past advisories and other computer security related information are available
for anonymous ftp from the cert.sei.cmu.edu (192.88.209.5) system.
Posted-Date:  Fri, 27 Sep 91 16:20:58 EDT
Received-Date:  Fri, 27 Sep 91 16:19:38 EDT
Full-Name:  John P. Wack
Organization:  National Institute of Standards and Technology (NIST)
Sub-Organization:  Computer Security Division
Return-Path:  <ecd@cert.sei.cmu.edu>
**************************************************************************
Security Bulletin 9123                  DISA Defense Communications System
7 November 1991             Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN is distributed  by the  DDN SCC  (Security
Coordination Center) under DISA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.112.36.5]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9123).
**************************************************************************

               NETWORK SECURITY TESTING AND MONITORING


    1. IN ACCORDANCE WITH NATIONAL TELECOMMUNICATIONS AND INFORMATION
       SYSTEMS SECURITY DIRECTIVE (NTISSD) NO. 600, "COMMUNICATIONS
       SECURITY (COMSEC) MONITORING," 10 APR 90 (FOUO), IT IS REQUIRED
       THAT USERS OF GOVERNMENT TELECOMMUNICATIONS SYSTEMS BE NOTIFIED
       IN ADVANCE THAT THEIR USE OF THESE SYSTEMS CONSTITUTES CONSENT
       TO MONITORING FOR COMSEC PURPOSES.  THE SAME APPLIES TO SECURITY
       TESTING OF AUTOMATED INFORMATION SYSTEMS AND NETWORKS.

    2. ADEQUATE NOTICE TO USERS CAN BE ACCOMPLISHED BY ANY OF THE
       FOLLOWING MEANS OR ANY COMBINATION THEREOF:

       (A). DISPLAYING A PRINTED MESSAGE DURING THE LOG-ON PROCESS.

       (B). DISPLAYING A PRINTED MESSAGE PERIODICALLY OR CONTINUALLY
            DURING SYSTEM OPERATION.

       (C). DECALS PLACED ON PROCESSING TERMINALS, TRANSMITTING AND
            RECEIVING DEVICES.

       (D). NOTICES IN DAILY BULLETINS OR SIMILAR MEDIUM.

       (E). A SPECIFIC MEMORANDUM TO USERS.

       (F). A STATEMENT IN THE STANDING OPERATING PROCEDURES,
            INSTRUCTIONS, OR SIMILAR DOCUMENTS.

    3. RECOMMEND, AS SOON AS POSSIBLE, ALL USERS OF THE DEFENSE DATA
       NETWORK (DDN) BE PUT ON NOTICE THAT THEIR USE OF THE DDN CONSTITUTES
       CONSENT TO SECURITY MONITORING AND SYSTEM TESTING.  PROPER
       NOTIFICATION IN TERMS OF CONTENT AND SPECIFICITY IS:

       "GOVERNMENT TELECOMMUNICATIONS SYSTEMS AND AUTOMATED INFORMATION
       SYSTEMS ARE SUBJECT TO A PERIODIC SECURITY TESTING AND MONITORING TO
       ENSURE PROPER COMMUNICATIONS SECURITY (COMSEC) PROCEDURES ARE BEING
       OBSERVED.  USE OF THESE SYSTEMS CONSTITUTES CONSENT TO SECURITY
       TESTING AND COMSEC MONITORING."

    4. ON DDN HOSTS WITH LIMITED CHARACTERS AVAILABLE IN THE LOG-IN
       BANNERS, ADEQUATE NOTICE WOULD BE PROVIDED BY DISPLAYING THE
       FOLLOWING:

       "USE CONSTITUTES CONSENT TO SECURITY TESTING AND MONITORING."

    5. POINT OF CONTACT IS MAJOR BOYD, CODE DODM, AT COMM (703) 692-7580
       OR DSN (312) 222-7580.
**************************************************************************
Security Bulletin 9127                  DISA Defense Communications System
19 December 1991            Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN is distributed  by the  DDN SCC  (Security
Coordination Center) under DISA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.112.36.5]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9127).
**************************************************************************

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center  distribution  system  as a  means  of        !
!     providing  DDN subscribers with useful security information.      !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

===========================================================================
CA-91:23                       CERT Advisory
			     December 18, 1991
            Hewlett Packard/Apollo Domain/OS crp Vulnerability
---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC)
has received information concerning a vulnerability in the crp facility
in Hewlett Packard/Apollo Domain/OS.  This vulnerability is present on all
HP/Apollo Domain/OS SR10 systems up through SR10.3.  Patches that address
this problem will be available in the SR10.3 patch tape (~Feb 92) and in
the SR10.4 software release.  Contact your local sales office for
more information.

---------------------------------------------------------------------------

I.   Description

     There is a security problem with the /usr/apollo/bin/crp facility.
     A user who is not running crp is not vulnerable to this problem.
 
II.  Impact

     A person at a remote or local site can obtain the privileges of
     the user who is running crp.

III. Workaround

     The suggested workaround is to disable two system calls that are
     made by /usr/apollo/bin/crp.  The following steps should be
     executed by root or another appropriate userid that has the
     privilege to write in the directories involved.

     1.	Create a file "crplib.c" containing the four-line C program:

	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 '-pic':

	(AEGIS)  /com/cc crplib.c -pic
	(UNIX)   /bin/cc -c crplib.c -W0,-pic
	
     3.	Copy the result to somewhere accessible to all users (/lib/crplib
	is recommended).
	
	(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.	a) Ensure that all users do an 'inlib' of that file before running crp.
	One way to ensure this would be to replace the /usr/apollo/bin/crp
	command by a shell script that does the inlib.  Doing this step
	will force crp to use the null functions defined in step 1 above.
	
	(AEGIS)  /com/chn /usr/apollo/bin/crp crp.orig
	(UNIX)   /bin/mv /usr/apollo/bin/crp /usr/apollo/bin/crp.orig
	
	b) Create the file /usr/apollo/bin/crp containing the shell script:
	
	(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 "$@"
	
	c) Make this script executable.

	(AEGIS)	/com/edacl -p root prwx -g wheel rx -w rx /usr/apollo/bin/crp
	(UNIX)	/bin/chmod 755 /usr/apollo/bin/crp

     ---------------

     NOTE: This workaround will prevent crp from making use of the two
     system calls; and therefore, it may affect the functionality of various
     software programs since they will be unable to define programmable
     function keys, create new windows on the client node, or execute
     background processes using the Display Manager interface.

---------------------------------------------------------------------------
The CERT/CC wishes to thank Paul Szabo of the University of Sydney for
bringing this problem to our attention and providing a workaround.
We would also like to thank Jim Richardson of the University of Sydney for
his assistance and Hewlett Packard/Apollo for their timely response to the
report of this vulnerability.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC via
telephone or e-mail.

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 (24-hour hotline)
           CERT/CC personnel answer 7:30a.m.-6:00p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories and other information related to computer security are
available for anonymous ftp from the cert.sei.cmu.edu (192.88.209.5) system.

**************************************************************************
Security Bulletin 9204                  DISA Defense Communications System
February 10, 1992           Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
Coordination Center) under DISA contract as a means of communicating
information on network and host security exposures, fixes, and concerns
to security and management personnel at DDN facilities.  Back issues may
be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
using login="anonymous" and password="guest".  The bulletin pathname is
scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. scc/ddn-security-9204).
**************************************************************************

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center  distribution  system  as a  means  of        !
!     providing  DDN subscribers with useful security information.      !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

===========================================================================
CA-92:02                        CERT Advisory
                               February 6, 1992
                         Michelangelo PC Virus Warning

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning a personal computer virus known as
Michelangelo.  The virus affects IBM PCs and compatibles.  A description
of the virus, along with suggested countermeasures, is presented below.

---------------------------------------------------------------------------

I.   Description

     The Michelangelo virus is a computer virus that affects PCs
     running MS-DOS (and PC-DOS, DR-DOS, etc.) versions 2.xx and
     higher.  Note, however, that although the virus can only execute
     on PCs running these versions of DOS, it can infect and damage PC
     hard disks containing other PC operating systems including UNIX,
     OS/2, and Novell.  Thus, booting an infected DOS floppy disk on
     a PC that has, for example, UNIX on the hard disk would infect
     the hard disk and would probably prevent the UNIX disk from
     booting.  The virus infects floppy disk boot sectors and hard
     disk master boot records (MBRs).  When the user boots from an
     infected floppy disk, the virus installs itself in memory and
     infects the partition table of the first hard disk (if found).
     Once the virus is installed, it will infect any floppy disk that
     the user accesses.

     Some possible, though not conclusive, symptoms of the
     Michelangelo virus include a reduction in free/total memory by
     2048 bytes, and some floppy disks that become unusable or display
     "odd" graphic characters during "DIR" commands.  Additionally,
     integrity management products should report that the MBR has been
     altered.

     Note that the Michelangelo virus does not display any messages on
     the PC screen at any time.

II.  Impact

     The Michelangelo virus triggers on any March 6.  On that date,
     the virus overwrites critical system data, including boot and
     file allocation table (FAT) records, on the boot disk (floppy or
     hard), rendering the disk unusable.  Recovering user data from a
     disk damaged by the Michelangelo virus will be very difficult.

III. Solution 

     Many versions of anti-virus software released after approximately
     October 1991 will detect and/or remove the Michelangelo virus.
     This includes numerous commercial, shareware, and freeware
     software packages.  Since this virus was first detected around
     the middle of 1991 (after March 6, 1991), it is crucial to use
     current versions of these products, particularly those products
     that search systems for known viruses.
        
     The CERT/CC has not formally reviewed, evaluated, or endorsed any
     of the anti-virus products.  While some older anti-virus products
     may detect this virus, the CERT/CC strongly suggests that sites
     verify with their anti-virus product vendors that their product
     will detect and eradicate the Michelangelo virus.

     The CERT/CC advises that all sites test for the presence of this
     virus before March 6, which is the trigger date.  If an infection
     is discovered, it is essential that the user examine all floppy
     disks that may have come in contact with an infected machine.

     As always, the CERT/CC strongly urges all sites to maintain good
     backup procedures.

---------------------------------------------------------------------------

The CERT/CC wishes to thank for their assistance: Mr. Christoph
Fischer of the Micro-BIT Virus Center (Germany), Dr. Klaus Brunnstein
of the Virus Test Center (Germany), Mr. A. Padgett Peterson, P.E., of
the Technical Computing Center at Martin-Marietta Corp., and Mr. Steve
R. White of IBM's Thomas J. Watson Research Center.

---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC or
your representative in FIRST (Forum of Incident Response and Security Teams).

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 (24-hour hotline)
           CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous ftp
from cert.sei.cmu.edu (192.88.209.5).


**************************************************************************
Security Bulletin 9208                  DISA Defense Communications System
9 March 1992                Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
Coordination Center) under DISA contract as a means of communicating
information on network and host security exposures, fixes, and concerns
to security and management personnel at DDN facilities.  Back issues may
be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
using login="anonymous" and password="guest".  The bulletin pathname is
scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. scc/ddn-security-9208).
**************************************************************************
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center  distribution  system  as a  means  of        !
!     providing  DDN subscribers with useful security information.      !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

=============================================================================
CA-92:05                        CERT Advisory
                                March 5, 1992
                        AIX REXD Daemon Vulnerability

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning a vulnerability with the rexd daemon
in versions 3.1 and 3.2 of AIX for IBM RS/6000 machines.

IBM is aware of the problem and it will be fixed 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.

The fix is also provided below.

---------------------------------------------------------------------------

I.   Description

     In certain configurations, particularly if NFS is installed,
     the rexd (RPC remote program execution) daemon is enabled.

     Note: Installing NFS with the current versions of "mknfs" will
     re-enable rexd even if it was previously disabled.

II.  Impact

     If a system allows rexd connections, anyone on the Internet can
     gain access to the system as a user other than root.

III. Solution 

     CERT/CC and IBM 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
         placing 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


---------------------------------------------------------------------------
The CERT/CC wishes to thank Darren Reed of the Australian National
University for bringing this vulnerability to our attention and
IBM for their response to the problem.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC or
your representative in FIRST (Forum of Incident Response and Security Teams).

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 (24-hour hotline)
           CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous ftp
from cert.sei.cmu.edu (192.88.209.5).

Posted-Date:  Thu, 5 Mar 92 14:05:19 EST
Received-Date:  Thu, 5 Mar 92 14:03:06 EST
Return-Path:  <ecd@cert.sei.cmu.edu>
 

****************************************************************************

The point of contact for MILNET security-related incidents is the
DDN Security Coordination Center (SCC).

E-mail address: SCC@NIC.DDN.MIL

Telephone: 1-(800)-365-3642
      NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,
      Monday through Friday except federal holidays.

****************************************************************************

**************************************************************************
Security Bulletin 9212                  DISA Defense Communications System
April 10, 1992              Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

  The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
  Coordination Center) under DISA contract as a means of communicating
  information on network and host security exposures, fixes, and concerns
  to security and management personnel at DDN facilities.  Back issues may
  be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  using login="anonymous" and password="guest".  The bulletin pathname is
  scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  and "nn" is a bulletin number, e.g. scc/ddn-security-9212).
**************************************************************************
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center  distribution  system  as a  means  of        !
!     providing  DDN subscribers with useful security information.      !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
===========================================================================
CA-92:08                       CERT Advisory
                              April 10, 1992
        Silicon Graphics Computer Systems "IRIX" lp Vulnerability

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning a method of unauthorized root access
in the lp software in Silicon Graphics Computer Systems (SGI) IRIX
operating systems.  This vulnerability is present in all current
versions of IRIX.

Silicon Graphics Computer Systems and the CERT/CC strongly recommend
that sites take immediate action to eliminate this vulnerability from
their systems.

This vulnerability will be fixed in IRIX 4.0.5 and is NOT present in any
version of the Trusted IRIX/B product.

---------------------------------------------------------------------------

I.   Description

     When IRIX pre-4.0.5 systems are installed or updated using either
     the basic system software ("eoe1.sw.unix") or the system manager
     software ("eoe2.sw.vadmin") media, a vulnerability is introduced
     in the lp software.

II.  Impact

     Any user logged into the system can gain root access.

III. Solution

     As root, execute the following commands:

        # cd /usr/lib
        # chmod a-s,go-w lpshut lpmove accept reject lpadmin
        # chmod go-ws lpsched vadmin/serial_ports vadmin/users vadmin/disks
        # cd /usr/bin
        # chmod a-s,go-w disable enable
        # chmod go-ws cancel lp lpstat

     If the eoe2.sw.vadmin software is not installed, you may
     ignore any warning messages from chmod such as:

       "chmod: WARNING: can't access vadmin/serial_ports"

     If system software should ever be reinstalled from pre-4.0.5
     media or restored from a backup tape created before the patch was
     applied, repeat the above procedure before enabling logins by
     normal users.

---------------------------------------------------------------------------
The CERT/CC would like to thank Silicon Graphics Computer Systems for 
bringing this security vulnerability to our attention and for their quick
response to this problem.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC or
your representative in FIRST (Forum of Incident Response and Security Teams).

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 (24-hour hotline)
           CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous ftp
from cert.sei.cmu.edu (192.88.209.5).

****************************************************************************
*                                                                          *
*    The point of contact for MILNET security-related incidents is the     *
*    Security Coordination Center (SCC).                                   *
*                                                                          *
*               E-mail address: SCC@NIC.DDN.MIL                            *
*                                                                          *
*               Telephone: 1-(800)-365-3642                                *
*                                                                          *
*    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
*    Monday through Friday except on federal holidays.                     *
*                                                                          *
****************************************************************************
**************************************************************************
Security Bulletin 9216                  DISA Defense Communications System
May 28, 1992                Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

  The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
  Coordination Center) under DISA contract as a means of communicating
  information on network and host security exposures, fixes, and concerns
  to security and management personnel at DDN facilities.  Back issues may
  be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  using login="anonymous" and password="guest".  The bulletin pathname is
  scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  and "nn" is a bulletin number, e.g. scc/ddn-security-9216).
**************************************************************************

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center  distribution  system  as a  means  of        !
!     providing  DDN subscribers with useful security information.      !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

===========================================================================
CA-92:12                      CERT Advisory
                              May 28, 1992
         Revised Patch for SunOS /usr/etc/rpc.mountd Vulnerability

---------------------------------------------------------------------------

                   *** THIS IS A REVISED CERT ADVISORY ***
          *** IT CONTAINS NEW VULNERABILITY AND PATCH INFORMATION ***
                  *** SUPERSEDES CERT ADVISORY CA-91:09 ***

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning the availability of a revised security
patch for /usr/etc/rpc.mountd in Sun Microsystems Computer Corporation
operating systems.  This patch fixes an additional vulnerability that
was not addressed in CERT advisory CA-91:09.SunOS.rpc.mountd.vulnerability.

Sun has provided patches for SunOS 4.1, SunOS 4.1_PSR_A, SunOS 4.1.1,
and SunOS 4.1.2.  These patches are available through your local Sun
Answer Center as well as through anonymous ftp from ftp.uu.net (137.39.1.9)
in the /systems/sun/sun-dist directory.

Patch ID and file information are as follows:

Fix                     Patch ID       Filename            Checksum
/usr/etc/rpc.mountd     100296-02      100296-02.tar.Z     30606    23

Please note that Sun Microsystems sometimes updates patch files.  If you
find that the checksum is different, please contact Sun Microsystems or
the CERT/CC for verification.

---------------------------------------------------------------------------
I.   Description

     Under certain conditions an exported NFS filesystem can be
     mounted by any system on the Internet even though it may appear
     that access to the filesystem is restricted to specific hosts.

II.  Impact

     Unauthorized remote hosts will be able to mount the exported filesystem.

III. Solution

     As root:

     1.  Move the existing rpc.mountd aside and change the permissions.

         # mv /usr/etc/rpc.mountd /usr/etc/rpc.mountd.OLD
         # chmod 400 /usr/etc/rpc.mountd.OLD

     2.  Install the new version

         # cp `arch`/rpc.mountd /usr/etc
         # chown root.staff /usr/etc/rpc.mountd
         # chmod 755 /usr/etc/rpc.mountd

     3.  Kill the currently running rpc.mountd and restart it, or
         reboot the system.  In either case, systems with filesystems
         mounted from this host will have interruptions in service.

---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC or
your representative in FIRST (Forum of Incident Response and Security Teams).

Internet E-mail: cert@cert.org
Telephone: 412-268-7090 (24-hour hotline)
           CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous ftp
from cert.org (192.88.209.5).

****************************************************************************
*                                                                          *
*    The point of contact for MILNET security-related incidents is the     *
*    Security Coordination Center (SCC).                                   *
*                                                                          *
*               E-mail address: SCC@NIC.DDN.MIL                            *
*                                                                          *
*               Telephone: 1-(800)-365-3642                                *
*                                                                          *
*    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
*    Monday through Friday except on federal holidays.                     *
*                                                                          *
****************************************************************************
**************************************************************************
Security Bulletin 9220                  DISA Defense Communications System
July 28, 1992               Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

  The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
  Coordination Center) under DISA contract as a means of communicating
  information on network and host security exposures, fixes, and concerns
  to security and management personnel at DDN facilities.  Back issues may
  be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  using login="anonymous" and password="guest".  The bulletin pathname is
  scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  and "nn" is a bulletin number, e.g. scc/ddn-security-9220).

**************************************************************************

                   CORRUPTED VERSIONS OF PKZIP UTILITIES
                               July 27, 1992

	
I.   DESCRIPTION

     ASSIST has learned that two corrupt versions of the popular archiving
     utility PKZIP for PC-DOS and MS-DOS machines are being circulated on
     several bulletin board systems around the country.  The two corrupted
     versions 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 these utilities.

     At the current time, the released version of PKZIP is version 1.10.
     A new version of PKZIP is expected to be released within the next
     few months.  Its version number may be 2.00, or it may be a version
     number greater than 2.2 to distinguish it from the corrupted versions.
     PKWARE INC. has indicated it will never issue a version 2.01 or 2.2
     of PKZIP.

II.  IMPACT

     THE DESTRUCTION OF ALL THE DATA ON YOUR HARD DISK IS A POSSIBILITY IF
     THE PROGRAMS ARE EXECUTED.
 
III. SOLUTION

     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 the C:(BACKSLASH) and
     C:(BACKSLASH)DOS directories.  If the hard disk has been erased by this
     program, recovery may be possible by utilizing 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 the files have been undeleted to avoid overwriting the deleted
     files, which will destroy them.

     To examine a file to determine 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:(BACKSLASH)(ASTERISK).(ASTERISK), or 

     DEL C:(BACKSLASH)(DOS)(BACKSLASH)(ASTERISK).(ASTERISK)

     then you have the corrupted file.

     Any freeware or shareware program downloaded from a BBS should be scanned
     and evaluated by a knowledgeable AIS person on a standalone PC before the
     program is introduced into any system.  If you or anyone else at your site
     should happen to encounter any corrupted files on a BBS, Please contact
     the ASSIST immediately
 
     PKWARE Inc. has also requested that they be informed of any occurrences of
     corrupted PKZIP files.  PKWARE Inc. can be reached at (414) 354-8699
     (voice), (414) 354-8670(BBS), (414) 354-8559(FAX).
 
     The ASSIST Point of Contact for this matter is Mr. Mike Higgins,
     COMM (202) 373-8852/55 or DSN 243-8852/55.

     ASSIST can be reached 24 hours a day via commercial pager at
     1-(800) SKY-PAGE, PIN NUMBER 2133937 (FROM A TOUCH TONE PHONE ENTER
     THE CALL BACK NUMBER AFTER THE PROMPT) or AUTOVON dial 243-8000 and
     ask to have the ASSIST Duty Officer paged.  ASSIST can also be reached
     via E-Mail at "DOD-CERT(AT-SIGN)DDN-CONUS.DDN.MIL."

****************************************************************************
*                                                                          *
*    The point of contact for MILNET security-related incidents is the     *
*    Security Coordination Center (SCC).                                   *
*                                                                          *
*               E-mail address: SCC@NIC.DDN.MIL                            *
*                                                                          *
*               Telephone: 1-(800)-365-3642                                *
*                                                                          *
*    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
*    Monday through Friday except on federal holidays.                     *
*                                                                          *
****************************************************************************
**************************************************************************
Security Bulletin 9224                  DISA Defense Communications System
October 6, 1992             Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

  The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
  Coordination Center) under DISA contract as a means of communicating
  information on network and host security exposures, fixes, and concerns
  to security and management personnel at DDN facilities.  Back issues may
  be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  using login="anonymous" and password="guest".  The bulletin pathname is
  scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  and "nn" is a bulletin number, e.g., scc/ddn-security-9224).
**************************************************************************
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important advisory was issued by the Computer       !
!     Emergency Response Team (CERT) and is being relayed unedited      !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center distribution system as a means of             !
!     providing DDN subscribers with useful security information.       !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
==========================================================================
CA-92:17           	         CERT Advisory
                            October 5, 1992
                 Hewlett-Packard NIS ypbind Vulnerability

--------------------------------------------------------------------------

The CERT Coordination Center has received information concerning a
vulnerability in the NIS ypbind module for the Hewlett-Packard (HP)
HP/UX Operating System for series 300, 700, and 800 computers. 

HP is aware of the problem and has produced patches for HP/UX 8.xx
versions.  This problem is fixed in HP/UX 9.0.

Architecture  Patch ID    Filename                               Checksum

Series 300    PHNE_1359   /hp-ux_patches/s300_400/8.X/PHNE_1359   39206 214
Series 700    PHNE_1360   /hp-ux_patches/s700/8.X/PHNE_1360       37915 299
Series 800    PHNE_1361   /hp-ux_patches/s800/8.X/PHNE_1361       44288 299

The checksums listed above are for the patch archive files from HP.
Once unpacked, each shell archive contains additional checksum 
information in the file "patchfilename.text".  This checksum is
applicable to the binary patch file "patchfilename.updt".

These patches may be obtained from HP via ftp (this is NOT anonymous ftp)
or the HP SupportLine.  To obtain HP security patches, you must first
register with the HP SupportLine.  The registration instructions provided
below will not be included in future advisories.

If you have any questions about obtaining or installing the patches,
contact the USA HP SupportLine at 415-691-3888 or your local HP
SupportLine number.  Please note that the telephone numbers in this
advisory are for the USA and Canada. 

--------------------------------------------------------------------------

I.   Description

     A vulnerability in HP NIS allows remote NIS servers unauthorized
     access to local NIS hosts.  An HP NIS client will accept ypset
     requests from hosts outside its NIS domain.

II.  Impact

     Root on a remote host running any vendor's implementation of NIS
     can gain root access on any local host running HP's NIS ypbind. 

III. Solution
        
     All HP NIS clients and servers running ypbind should obtain and 
     install the patch, as detailed below.

     The sections below include 1) instructions for registering with the
     HP SupportLine and obtaining the HP security patches, and
     2) instructions for installing the patch provided by HP.
     The instructions for installing the patch are also provided in the
     PHNE_xxxx.text file (this file is created after the patch has been
     unpacked). 

=========================================================================
             Beginning of Text provided by Hewlett-Packard
=========================================================================
HP SupportLine Registration Instructions

HP SupportLine phone number:  415-691-3888.

Customers in three categories are eligible to obtain the security patches:

 1) HP SupportLine customers who have a software support contract or
    have recently purchased an HP 9000 and who access the SupportLine
    via a terminal or modem.
 2) HP SupportLine customers who have access via Internet.
 3) Customers not currently accessing the HP SupportLine.

For category 1:
---------------
Step 1: Dial 415-691-3680.

Step 2: When your communications program indicates that you are
connected, press "return".  The system prompt, ":" or "login:",
should appear.

Step 3: If your system prompt is ":", log on to the HP SupportLine 
account by typing "HELLO USER.HPSL", followed by "return".

        If your system prompt is "login:", log on by typing "login: hpsl",
followed by "return".

Step 4: When prompted, type your system handle and password; follow each
with "return".  Your system handle and password are provided in the
cover letter you received with your "Getting Started Kit." 

Step 5: Press "return" until the HP SupportLine Top Menu screen is
displayed.  If your terminal does not support block mode, enable HPSL's
line editor by typing "SET EDITOR LINE" at the command prompt and entering
"return". 

For category 2:
---------------
Step 1: HP 9000, HP Apollo, and HP 64000 system users who have been 
authorized by the National Science Foundation (NSF) to use Internet
may access HP SupportLine over the Internet.  Connect to HP SupportLine
using the address provided in your "Getting Started Kit."  U.S. login
examples are

        telnet 192.6.148.19
                 or
        telnet support.mayfield.hp.com

Step 2: Once you access HP SupportLine, type "hpsl" at the "login:" 
prompt. 

Step 3: When prompted, enter your system handle and password; follow each 
with "return".  Your system handle and password are provided in the cover
letter you received with your "Getting Started Kit." 

Step 4: Press "return" until the HP SupportLine Top Menu is displayed. 


Step 5: At the Top Menu, choose "3   Patch support information" by 
typing "3" at the "Select an item or enter a command (? for help) :"
prompt.  This will put you in the Patch Support Information Menu.

Step 6: At the Patch Support Information Menu, choose "3   Retrieve 
patch file transfer login" to get your patch file transfer login by
typing "3" at the "Select an item or enter a command (? for help) :"
prompt.  This will put you at a screen that allows you to choose the
method for patch file transfers.  The choices are ftp, kermit, and uucp.
To choose ftp, type "1" at the "Enter selection :" prompt.  The next
screen will display your patch file transfer method and your patch file
transfer login.  You will use the *SAME* patch file login when you ftp
patch file(s).  

Step 7:  When you exit the HP SupportLine, by typing "E" at the
"Select an item or enter a command (? for help) :" prompt, the
connection is closed. 

Step 8:  FTP to

		192.6.148.19
		     or
		support.mayfield.hp.com

Step 9:  At the "Name (support.mayfield.hp.com:username):" prompt,
type your patch file transfer login.

Step 10: At the "Password:" prompt, type the password assigned to
you by Hewlett-Packard when you registered.

Step 11: At the "ftp>" prompt, set the transfer mode to binary by
typing "bin".  You should get a message "Type set to I".

Step 12: At the "ftp>" prompt, cd to "hp-ux_patches".  Then cd to the
directory named for your type of architecture (s300_400, s700, or
s800).  Then cd to "8.X".

Step 13: At the "ftp>" prompt, type "get PHNE_xxxx" (where xxxx is
1359, 1360, or 1361 - depending on the architecture of your host(s)).

For category 3:
---------------
Step 1: Dial 415-691-3680.

Step 2: Type "hpslreg" at the "login:" prompt to begin the registration
process. 

Step 3: Follow the instructional prompts.

Step 4: Once you have received your HP SupportLine system handle and 
password, follow the directions in category 1) or 2), depending on
your preferred access method.


========================================================================
Patch Installation Instructions 

Item Subject: PHNE_1359.text
Patch Name:   PHNE_1359

Patch Description: ypbind that accepts ypset only from local host

This patch provides a special version of ypbind that accepts ypset
requests only from the local host.  This prevents a superuser on a
remote system from issuing a ypset -h command to the local system to
create a rogue ypserver.

Path Name:  /hp-ux_patches/s300_400/8.X/PHNE_1359

Effective Date:  920810

Patch Files:  ypbind

SR#:  1650-172619

"what" string/timestamp:
    ypbind
        ypbind:  $Revision:  1.43.108.1.1.1 $ $Date:  91/12/12 18:10:30
        $

"sum" output:
    46857 200 ypbind

Dependencies:  None.

Supersedes:  None.

Patch Package Size:  134 Kbytes

Installation Instructions: 

     Before installing this patch, please review all instructions and
     the Hewlett-Packard SupportLine User Guide or your Hewlett-Packard
     support terms and conditions for precautions, scope of license,
     restrictions, and limitation of liability and warranties,

     Note: Please back up your system before you patch.

------------------------------------------------------------------------

After getting the patch onto your machine, unshar the patch 
(sh PHNE_1359). 

To install this patch, do the following:

1)  Run the update program. (Note: you must be logged in as root to
    update a system.)
2)  Once in the update "Main Menu", move the highlighted line to "Change 
    Source or Destination ->" and press "Return" or "Select Item".
3)  Make sure the highlighted item in the "Change Source or Destination"
    window is "From Tape Device to Local System ...", then press "Return"
    or "Select Item".
4)  You should now be in the "From Tape Device to Local System" window. 
    Change the "Source:  /dev/rmt/0m" to "Source: /tmp/PHNE_1359.updt" 
    (this assumes that you are in the /tmp directory where
    PHNE_1359.updt has been placed).  Note: You must enter the complete
    path name. 
5)  Press "Done".
6)  From here on, follow the standard directions for update.

The customized script that update runs will move the original software 
to /system/PHNE_1359/orig.  In order to recover from any potential problems,
HP recommends keeping the software there.  HP also recommendeds that you
move the PHNE_1359.text file to /system/PHNE_1359 and retain it for future
reference.

If you wish to put this patch on a magnetic tape and update from the
tape drive, dd a copy of the patch to the tape drive.  As an example,
the following will create a copy of the patch that update can read: 

dd if=PHNE_1359.updt of=/dev/rmt/0m bs=2048

.......................................................................

Item Subject: PHNE_1360.text
Patch Name:  PHNE_1360

Patch Description: ypbind that accepts ypset only from local host

This patch provides a special version of ypbind that accepts ypset
requests only from the local host.  This prevents a superuser on a remote
system from issuing a ypset -h command to the local system to create a
rogue ypserver.

Path Name:  /hp-ux_patches/s700/8.X/PHNE_1360

Effective Date:  920810

Patch Files:  ypbind

SR#:  1650-172619

"what" string/timestamp:
    ypbind
        ypbind:  $Revision:  1.43.108.1.1.1 $ $Date:  91/12/12 18:10:30
        $

"sum" output:
    48068 256 ypbind

Dependencies:  None.

Supersedes:  None.

Patch Package Size:  164 Kbytes

Installation Instructions: 

     Before installing this patch, please review all instructions and
     the Hewlett-Packard SupportLine User Guide or your Hewlett-Packard
     support terms and conditions for precautions, scope of license,
     restrictions, and limitation of liability and warranties.
     
     Note: Please back up your system before you patch.

---------------------------------------------------------------------------

After getting the patch onto your machine, unshar the patch 
(sh PHNE_1360).

To install this patch do the following:
1)  Run the update program.  (Note: you must be logged in as root to
    update a system.)
2)  Once in the update "Main Menu", move the highlighted line to "Change 
    Source or Destination ->" and press "Return" or "Select Item".
3)  Make sure the highlighted item in the "Change Source or Destination"
    window is "From Tape Device to Local System ...", then press "Return"
    or "Select Item".
4)  You should now be in the "From Tape Device to Local System" window. 
    Change the "Source:  /dev/rmt/0m" to "Source: /tmp/PHNE_1360.updt" 
    (this assumes that you are in the /tmp directory where
    PHNE_1360.updt has been placed).  Note: You must enter the complete
    path name. 
5)  Press "Done".
6)  From here on, follow the standard directions for update.

The customized script that update runs will move the original software 
to /system/PHNE_1360/orig. In order to recover from any potential problems,
HP recommends keeping the software there.  HP also recommendeds that you
move the PHNE_1360.text file to /system/PHNE_1360 and retain it for future
reference.

If you wish to put this patch on a magnetic tape and update from the
tape drive, dd a copy of the patch to the tape drive.  As an example,
the following will create a copy of the patch that update can read: 

dd if=PHNE_1360.updt of=/dev/rmt/0m bs=2048

.......................................................................

Item Subject: PHNE_1361.text
Patch Name:  PHNE_1361

Patch Description: ypbind that accepts ypset only from local host

This patch provides a special version of ypbind that accepts ypset requests
only from the local host.  This prevents a superuser on a remote system
from issuing a ypset -h command to the local system to create a rogue
ypserver.

Path Name:  /hp-ux_patches/s800/8.X/PHNE_1361

Effective Date:  920810

Patch Files:  ypbind

SR#:  1650-172619

"what" string/timestamp:
    ypbind
        ypbind:  $Revision:  1.43.108.1.1.1 $ $Date:  91/12/12 18:10:30
        $

"sum" output:
    48068 256 ypbind

Dependencies:  None.

Supersedes:  None.

Patch Package Size:  164 Kbytes

Installation Instructions: 

     Before installing this patch, please review all instructions
     and the Hewlett-Packard SupportLine User Guide or your
     Hewlett-Packard support terms and conditions for precautions,
     scope of license, restrictions, and limitation of liability
     and warranties.
     
     Note: Please back up your system before you patch.

---------------------------------------------------------------------------

After getting the patch onto your machine, unshar the patch 
(sh PHNE_1361). 

To install this patch do the following:

1)  Run the update program. (Note: you must be logged in as root to
    update a system.)
2)  Once in the update "Main Menu", move the highlighted line to "Change 
    Source or Destination ->" and press "Return" or "Select Item".
3)  Make sure the highlighted item in the "Change Source or
    Destination" window is "From Tape Device to Local System ...", then
    press "Return" or "Select Item".
4)  You should now be in the "From Tape Device to Local System" window. 
    Change the "Source:  /dev/rmt/0m" to "Source: /tmp/PHNE_1361.updt" 
    (this assumes that you are in the /tmp directory where
    PHNE_1361.updt has been placed).  Note: You must enter the complete
    path name. 
5)  Press "Done".
6)  From here on, follow the standard directions for update.

The customized script that update runs will move the original software 
to /system/PHNE_1361/orig.  In order to recover from any potential problems,
HP recommends keeping this software there.  HP also recommendeds that you
move the PHNE_1361.text file to /system/PHNE_1361 and retain it for future
reference.

If you wish to put this patch on a magnetic tape and update from the
tape drive, dd a copy of the patch to the tape drive.  As an example
the following will create a copy of the patch that update can read:  

dd if=PHNE_1361.updt of=/dev/rmt/0m bs=2048

============================================================================
                 End of Text provided by Hewlett-Packard
============================================================================

-----------------------------------------------------------------------------
The CERT Coordination Center wishes to thank Brian Kelley of Ford
Motor Company for bringing this vulnerability to our attention.  We
would also like to thank Hewlett-Packard for their response to this
problem. 
-----------------------------------------------------------------------------

If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in FIRST (Forum of Incident
Response and Security Teams). 

Internet E-mail: cert@cert.org
Telephone: 412-268-7090 (24-hour hotline)
           CERT personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous ftp
from cert.org (192.88.209.5).


****************************************************************************
*                                                                          *
*    The point of contact for MILNET security-related incidents is the     *
*    Security Coordination Center (SCC).                                   *
*                                                                          *
*               E-mail address: SCC@NIC.DDN.MIL                            *
*                                                                          *
*               Telephone: 1-(800)-365-3642                                *
*                                                                          *
*    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
*    Monday through Friday except on federal holidays.                     *
*                                                                          *
****************************************************************************
**************************************************************************
Security Bulletin 9228                  DISA Defense Communications System
December 17, 1992           Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

  The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
  Coordination Center) under DISA contract as a means of communicating
  information on network and host security exposures, fixes, and concerns
  to security and management personnel at DDN facilities.  Back issues may
  be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  using login="anonymous" and password="guest".  The bulletin pathname is
  scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  and "nn" is a bulletin number, e.g. scc/ddn-security-9228).
**************************************************************************

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center  distribution  system  as a  means  of        !
!     providing  DDN subscribers with useful security information.      !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

CA-92:21                      CERT Advisory
                            December 16, 1992
                ConvexOS and ConvexOS/Secure Vulnerabilities

---------------------------------------------------------------------------

The CERT Coordination Center has received information concerning
several vulnerabilities in the following CONVEX Computer Corporation
products: ConvexOS/Secure, CONVEX CXbatch, CONVEX Storage Manager
(CSM), and ConvexOS EMACS.  These vulnerabilities can affect ConvexOS
versions V6.2 - V10.2 and ConvexOS/Secure versions V9.5 and V10.0 on
all supported architectures.

CONVEX is aware of the vulnerabilities, and fixes or workarounds are
available.  Three of the fixes are implemented as full Engineering
Change Notice (ECN) patches and, as such, will be shipped with all new
systems and will also be released as upgrades for the products
CXbatch, CSM and ConvexOS/Secure.  A workaround is available for
the ConvexOS EMACS vulnerability. CONVEX is currently incorporating
the fixes to these vulnerabilities into future releases of each
product.  Future shipments of these products should not be vulnerable
to these problems.

If you have any questions about the affected products, please contact
your CONVEX representative or the CONVEX Technical Assistance Center
(TAC) at 1-800-952-0379.

-----------------------------------------------------------------------------

ConvexOS/Secure: passwd patch

I.    Description

      The "passwd" command in ConvexOS/Secure contains a security
      vulnerability in versions V9.5 and V10.0 of ConvexOS/Secure.
      This vulnerability has been fixed in ConvexOS/Secure V10.1.

II.   Impact

      Local users can gain unauthorized root access.

III.  Solution

      Obtain and install ConvexOS/Secure V10.0.2 - Part No.
      710-007815-008.


------------------------------------------------------------------------------

Convex CXbatch: qmgr patch

I.    Description

      The "qmgr" command in CONVEX CXbatch versions V1.0 - V2.1.3
      contains a security vulnerability.  This vulnerability is 
      present in ConvexOS V6.2 - V10.2 on systems that have installed 
      the optional CXbatch facility.

II.   Impact

      Local users can gain unauthorized root access.

III.  Solution

      A.  As root, rename the existing version of /usr/convex/qmgr and
          modify the permission (from 6755 to 700) to prevent misuse.

          # /bin/mv /usr/convex/qmgr /usr/convex/qmgr.orig
          # /bin/chmod 700 /usr/convex/qmgr.orig

      B.  Next, obtain and install CONVEX CXbatch V2.1.4 - Part No.
          710-007830-011.

------------------------------------------------------------------------------

Convex CSM: migmgr patch

I.    Description

      The "migmgr" command in CONVEX CSM contains a security
      vulnerability, in ConvexOS version V10.1 of systems that have
      installed the CSM facility.  This vulnerability will be fixed
      in the next CSM release.

II.   Impact

      Local users can gain unauthorized root access.

III.  Solution

      A.  As root, rename the existing version of /usr/csm/bin/migmgr and
          modify the permission (from 4755 to 700) to prevent misuse.

          # /bin/mv /usr/csm/bin/migmgr /usr/csm/bin/migmgr.orig
          # /bin/chmod 700 /usr/csm/bin/migmgr.orig

      B.  Next, obtain and install CONVEX CSM V1.0.1 - Part No.
          710-011315-003

------------------------------------------------------------------------------

ConvexOS: EMACS editor workaround

I.    Description

      The EMACS Editor in ConvexOS contains a security vulnerability,
      in ConvexOS versions V9.0 - V10.2.

II.   Impact

      Local users can gain unauthorized access to /dev/kmem.

III.  Solution

      As root, remove the setgid bit from /usr/convex/emacs.

          # /bin/chmod 755 /usr/convex/emacs

------------------------------------------------------------------------------ 
The CERT Coordination Center wishes to thank the CONVEX Computer
Corporation for their response to these problems.  We would also like
to thank Bob Vickers from the University of London Computer Centre,
London, England, for reporting the CXbatch problem to us.
------------------------------------------------------------------------------ 

If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in FIRST (Forum of Incident
Response and Security Teams).

Internet E-mail: cert@cert.org
Telephone: 412-268-7090 (24-hour hotline)
           CERT personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous FTP
from cert.org (192.88.209.5).


****************************************************************************
*                                                                          *
*    The point of contact for MILNET security-related incidents is the     *
*    Security Coordination Center (SCC).                                   *
*                                                                          *
*               E-mail address: SCC@NIC.DDN.MIL                            *
*                                                                          *
*               Telephone: 1-(800)-365-3642                                *
*                                                                          *
*    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
*    Monday through Friday except on federal holidays.                     *
*                                                                          *
****************************************************************************
[scc/00scc-index.]                                         [6-92]

DDN-SECURITY-8901..........DDN SECURITY COORDINATION CENTER OPERATIONAL
                            (22-Sep-89)
DDN-SECURITY-8902..........COLUMBUS DAY / OCTOBER 12TH / FRIDAY THE
                            13TH / DATACRIME VIRUS (05-Oct-89)
DDN-SECURITY-8903..........W.COM ("WANK") WORM ON SPAN NETWORK
                            (18-Oct-89)
DDN-SECURITY-8904..........HALLOWEEN PRECAUTIONARY NOTE (23-Oct-89)
DDN-SECURITY-8905..........ULTRIX 3.0 BREAK-IN ATTEMPTS (23-Oct-89)
DDN-SECURITY-8906..........SUN RCP VULNERABILITY (1-NOV-89)
DDN-SECURITY-9001..........SECURITY VIOLATION REPORTING (25-JAN-90)
DDN-SECURITY-9002..........SUN SENDMAIL VULNERABILITY (30-JAN-90)
DDN-SECURITY-9003..........SECURITY VIOLATION REPORTING (15-FEB-90)
DDN-SECURITY-9004..........COMPUTER SYSTEM "WELCOME" BANNERS (2-MAR-90)
DDN-SECURITY-9005..........INTERNET INTRUDER WARNING (20-MAR-90)
DDN-SECURITY-9006..........PRECAUTIONARY NOTE (27-MAR-90)
DDN-SECURITY-9007..........FEDERAL INFORMATION PROCESSING STANDARDS
                            AVAILABLE ONLINE (9-APR-90)
DDN-SECURITY-9008..........UNISYS U5000 /etc/passwd PROBLEM (7-MAY-90)
DDN-SECURITY-9009..........SunView selection_svc vulnerability (16-AUG-90)
DDN-SECURITY-9010..........Sun Microsystems Customer Warning System
                           Established (16-AUG-90)
DDN-SECURITY-9011..........NeXT's System Software: Four Problems (3-OCT-90)
DDN-SECURITY-9012..........VMS SECURITY PROBLEM (29-OCT-90)
DDN-SECURITY-9101..........SunOS /bin/mail Vulnerability (22-FEB-91)
DDN-SECURITY-9102..........REVISED SunOS /bin/mail Vulnerability (25-FEB-91)
DDN-SECURITY-9103..........Patch Available for SunOS in.telnetd (27-MAR-91)
DDN-SECURITY-9104..........Unauthorized Password Change Requests
                           Via Mail Messages (5-APR-91)
DDN-SECURITY-9105..........Alert Regarding Masquerading Activities (20-APR-91)
DDN-SECURITY-9106..........DEC Ultrix chroot Vulnerability (1-May-91)
DDN-SECURITY-9107..........NeXT rexd, /private/etc, Username me
                           Vulnerabilities (20-May-91)
DDN-SECURITY-9108..........AT&T System V Release 4 /bin/login Vulnerability
                           (23-May-91)
DDN-SECURITY-9109..........Patch for SunOS /usr/etc/rpc.mountd (23-Jul-91)
DDN-SECURITY-9110..........Patch for SunOS /usr/lib/lpd (23-Jul-91)
DDN-SECURITY-9111..........ULTRIX LAT/Telnet Gateway Vulnerability (15-Aug-91
DDN-SECURITY-9112..........Trusted Hosts Configuration Vulnerability 
                           (23-Aug-91)
DDN-SECURITY-9113..........DEC ULTRIX /usr/bin/mail Vulnerability (23-Aug-91)
DDN-SECURITY-9114..........SGI "IRIX" /usr/sbin/fmt Vulnerability (27-Aug-91)
DDN-SECURITY-9115..........Mac/PC NCSA Telnet Vulnerability (11-Sep-91)
DDN-SECURITY-9116..........New Patch for SunOS /usr/lib/lpd (16-Sep-91
DDN-SECURITY-9117..........SunOS SPARC Integer Division Vulnerability
                           (18-Sep-91)
DDN-SECURITY-9118..........Vulnerability of DECnet-Internet gateway software 
                           in DEC ULTRIX versions (1-Oct-91)
DDN-SECURITY-9119..........Active Internet tftp Attacks (1-Oct-91)
DDN-SECURITY-9120..........Re-registration of TAC Users (21-Oct-91)
DDN-SECURITY-9121..........AIX TFTP Daemon Vulnerability (21-Oct-91)
DDN-SECURITY-9122........../usr/ucb/rdist Vulnerability (23-Oct-91)
DDN-SECURITY-9123..........NETWORK SECURITY TESTING AND MONITORING (7-Nov-91)
DDN-SECURITY-9124..........CERT/CC Generic Security Information (5-Dec-91)
DDN-SECURITY-9125..........SunOS NFS Jumbo and fsirand Patches (9-Dec-91)
DDN-SECURITY-9126..........SunOS SunOS OpenWindows V3.0 Patch (19-Dec-91)
DDN-SECURITY-9127..........Hewlett Packard/Apollo Domain/OS crp Vulnerability
                           (19-Dec-91)
DDN-SECURITY-9201..........NeXTstep Configuration Vulnerability (22-Jan-92)
DDN-SECURITY-9202..........TAC Security (23-Jan-92)
DDN-SECURITY-9203..........REGISTRATION OF TAC USERS (4-Feb-92)
DDN-SECURITY-9204..........Michelangelo PC Virus Warning (10-Feb-92)
DDN-SECURITY-9205..........Internet Intruder Activity (17-Feb-92)
DDN-SECURITY-9206..........New Macintosh Virus Discovered (24-Feb-92)
DDN-SECURITY-9207..........AT&T /usr/etc/rexecd Vulnerability (26-Feb-92)
DDN-SECURITY-9208..........AIX REXD Daemon Vulnerability (9-Mar-92)
DDN-SECURITY-9209..........AIX uucp Vulnerability (19-Mar-92)
DDN-SECURITY-9210..........Macintosh INIT 1984 Virus Discovered (19-Mar-92)
DDN-SECURITY-9211..........AIX /bin/passwd Vulnerability (1-Apr-92)
DDN-SECURITY-9212..........Silicon Graphics Computer Systems "IRIX" lp 
                           Vulnerability(15-Apr-91)
DDN-SECURITY-9213..........AIX Anonymous FTP Vulnerability (29-Apr-92)
DDN-SECURITY-9214..........AIX crontab Vulnerability (27-May-92)
DDN-SECURITY-9215..........SunOS Environment Variables and setuid/setgid
                           Vulnerability (27-May-92)
DDN-SECURITY-9216..........REVISED Patch for SunOS /usr/etc/rpc.mountd
                           Vulnerability (28-May-92)
DDN-SECURITY-9217..........SunOS NIS Vulnerability (8-Jun-92)
DDN-SECURITY-9218..........Altered System Binaries Incident (23-Jun-92)
DDN-SECURITY-9219..........Multiple SunOS Vulnerabilities Patched (22-Jul-92)
DDN-SECURITY-9220..........Corrupted Versions of PKZIP Utilities (28-Jul-92)
DDN-SECURITY-9221..........Virus Alert - Aliens4 (14-Aug-92)
DDN-SECURITY-9222..........Aliens4 - Epilogue (25-Aug-92)
DDN-SECURITY-9223..........VMS Monitor Vulnerability (24-Sep-92)
DDN-SECURITY-9224..........Hewlett-Packard NIS ypbind Vulnerability (6-Oct-92)
DDN-SECURITY-9225..........TAC Access Control Policy Cir. Announcement (7-Oct-92)
DDN-SECURITY-9226..........Revised VMS Monitor Vulnerability (19-Nov-92)
                           Supersedes DDN-SECURITY-9223
DDN-SECURITY-9227..........Cisco Access List Vulnerability (11-Dec-92)
DDN-SECURITY-9228..........ConvexOS and ConvexOS/Secure Vulnerabilities (17-Dec-92)
DDN-SECURITY-9301..........Revised HP NIS ypbind Vulnerability (14-Jan-93)
                           Supersedes DDN-SECURITY-9224
DDN-SECURITY-9302..........NeXT NetInfo "_writers" Vulnerabilities (21-Jan-93)
DDN-SECURITY-9303..........NeXT NetInfo "_writers" Vulnerabilities (22-Jan-93)
                           REVISED VERSION of DDN-SECURITY-9302


DCA_Circular.310-P115-1....COMMUNICATIONS SECURITY (4-Feb-92)



FIPS_500_166.TXT............COMPUTER VIRUSES AND RELATED THREATS: A
                            MANAGEMENT GUIDE (SEP-89)
FIPS_500_166.PS.............COMPUTER VIRUSES AND RELATED THREATS: A
                            MANAGEMENT GUIDE - POSTSCRIPT VERSION
FIPS_500_169.TXT............EXECUTIVE GUIDE TO THE PROTECTION OF
                            INFORMATION RESOURCES (OCT-89)
FIPS_500_170.TXT............MANAGEMENT GUIDE TO THE PROTECTION OF
                            INFORMATION RESOURCES (OCT-89)
FIPS_500_171.TXT............COMPUTER USER'S GUIDE TO THE PROTECTION OF
                            INFORMATION RESOURCES (OCT-89)

**********************************************************************
 
DDN Security Bulletin 01         DCA DDN Defense Communications System
22 Sep 89               Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155
 
                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN
 
The DDN SECURITY  BULLETIN is distributed  online by the  DDN Security
Coordination Center  under DCA  contract as  a means  of communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be obtained via  FTP (or Kermit)  from the SRI-NIC  host [26.0.0.73 or
10.0.0.51] using login="anonymous" and password="guest".  The pathname
for  bulletins  is  DDN-NEWS:DDN-SECURITY-nn.TXT  (where  "nn"  is the
bulletin number).
 
**********************************************************************
 
             DDN SECURITY COORDINATION CENTER OPERATIONAL
 
1.  The Defense  Communications Agency has  created a facility to help
the  DDN  community  when  security-related  situations  occur.   The
function of the DDN Security Coordination Center (SCC) is to provide a
centralized and  coordinated capability  for the  rapid, reliable, and
secure distribution  and coordination of security  related information
between DDN users, operations staff, and system maintenance providers.
 
2.  The  Defense  Data  Network  Security  Coordination  Center is now
operational.
 
3.  In the past,  the unclassified  DoD Internet  has seen  a rash  of
security incidents.  Typically, these  incidents were due to  commonly
known  software  weaknesses  in  UNIX-based  host  products.   In  one
instance, the exposure had had a fix published several weeks before it
was  exploited  by  a  hacker.   DARPA  and other Agencies established
Computer Emergency Response  Teams (CERTs) to  report security-related
problems to vendors and assist in validating/verifying their fixes.
 
4.  But there was no central clearinghouse in place coordinating  and
disseminating security-related  fixes to  MILNET users.   In the past,
the  Network  Information  Center  (NIC)  had  been  pressed into this
service,  and  the  contractor  (SRI)  has  done an excellent job when
called upon.   But the NIC was never intended  to handle  such a task.
Now  DCA  has  funded  SCC  to  be  DDN's  clearinghouse for host/user
security problems and fixes and to work with the DDN Network  Security
Officer as needed.
 
5.  The SCC is ready to assist you with network-related host security
problems.  Call (800) 235-3155 (7:00 a.m. to 5:00 p.m. Pacific Time) or
send e-Mail to SCC@NIC.DDN.MIL.  For 24 hour coverage, call the MILNET
Trouble Desk (800) 451-7413 or AUTOVON 231-1713.
 
**********************************************************************

**********************************************************************
 
DDN Security Bulletin 03         DCA DDN Defense Communications System
18 Oct 89               Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155
 
                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN
 
The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [26.0.0.73 or
10.0.0.51] using login="anonymous" and password="guest".  The bulletin
pathname is SCC:DDN-SECURITY-nn (where "nn" is the bulletin number).
 
**********************************************************************
 
                 W.COM ("WANK") WORM ON SPAN NETWORK
 
On 16 October, the CERT received word from SPAN network control that a
worm was attacking SPAN VAX/VMS  systems.  This worm affects only  DEC
VMS  systems  and  is  propagated  via  DECnet (not TCP/IP) protocols.
At least  two versions  of this  worm exist  and more  may be created.
Non-VMS systems are immune; TCP/IP networks are not at risk.
 
While this program  is very similar to last year's HI.COM  (or "Father
Christmas") worm (see DDN MGT Bulletin #50  23 Dec 88),  THIS IS NOT A
PRANK.  Instead of a "cute" Christmas greeting,  W.COM appends code to
.com files and displays this banner:
 
      W O R M S    A G A I N S T    N U C L E A R    K I L L E R S
    _______________________________________________________________
    \__  ____________  _____    ________    ____  ____   __  _____/
     \ \ \    /\    / /    / /\ \       | \ \  | |    | | / /    /
      \ \ \  /  \  / /    / /__\ \      | |\ \ | |    | |/ /    /
       \ \ \/ /\ \/ /    / ______ \     | | \ \| |    | |\ \   /
        \_\  /__\  /____/ /______\ \____| |__\ | |____| |_\ \_/
         \___________________________________________________/
          \                                                 /
           \    Your System Has Been Officically WANKed    /
            \_____________________________________________/
 
     You talk of times of peace for all, and then prepare for war.
 
Initial reports described the worm as destructive, i.e. it would erase
files.  Detailed  analysis by  the CERT,  Lawrence Livermore  National
Laboratory, and  FermiLab has  not found  any code  that would perform
file erasures.   However,  files are altered and new accounts created.
Serious security holes are left open by this worm.
 
It is very  important to understand  that someone in  the future could
launch this  worm on  any DECnet  based network.   Many copies  of the
virus have been mailed around.  Anyone running a DECnet network should
be warned.
 
When  the  DDN  PMO  received  these  initial  reports, the MailBridge
filters were activated  to preclude any  traffic from passing  between
MILNET and the rest of the  Internet.   The filters will be turned off
(restoring full interoperability)  Tuesday  17 October 1989  NLT 17:00
EDT.   (NOTE:  W.COM could traverse the MILNET only if encapsulated in
a TCP/IP  "envelope",  i.e. "assisted" by  a human  agent,  and cannot
"infect" the MILNET.)
 
R. Kevin Oberman from Lawrence Livermore National Laboratory reports:
 
    "This is a mean bug to kill and could have done a lot of damage.
    Since it notifies (by mail) someone of each successful penetration
    and leaves a trapdoor (the FIELD account), just killing the bug is
    not adequate.  You must go in an make sure all accounts have
    passwords and that the passwords are not the same as the account
    name."
 
The CERT also suggests checking every  .com  file on the system.   The
worm appends  code to  .com  files which will  reopen a  security hole
every time the program is executed.
 
An analysis of the  worm  (provided by R. Kevin Oberman  and used with
his permission)  appears below.   Included with  the analysis is a DCL
program that will block the current version of the worm.  This program
should provide enough time to close up obvious security holes.
 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 
Date: Mon, 16 Oct 89 15:30 PDT
From: "Kevin Oberman, LLNL, (415)422-6955" <OBERMAN@icdc.llnl.gov>
Subject: Report on network worm ***URGENT***
 
 
 
                          Report on the W.COM worm.
                               R. Kevin Oberman
                            Engineering Department
                    Lawrence Livermore National Laboratory
                               October 16, 1989
 
The following describes the action of the W.COM worm (currently based on the
examination of the first two incarnations). The replication technique causes
the code to be modified slightly which indicates the source of the attack and
learned information.
 
All analysis was done with more haste than I care for, but I believe I have all
of the basic facts correct.
 
First a description of the program:
 
1. The program assures that it is working in a directory to which the owner
(itself) has full access (Read, Write,Execute, and Delete).
 
2. The program checks to see if another copy is still running. It looks for a
process with the first 5 characters of "NETW_". If such is found, it deletes
itself (the file) and stops its process.
 
                                     NOTE
A quick check for infection is to look for a process name starting with
"NETW_". This may be done with a SHOW PROCESS command.
 
3. The program then changes the default DECNET account password to a random
string of at least 12 characters.
 
4. Information on the password used to access the system is mailed to the user
GEMTOP on SPAN node 6.59. Some versions may have a different address.
 
5. The process changes its name to "NETW_" followed by a random number.
 
6. It then checks to see if it has SYSNAM priv. If so, it defines the system
announcement message to be the banner in the program:
      W O R M S    A G A I N S T    N U C L E A R    K I L L E R S
    _______________________________________________________________
    \__  ____________  _____    ________    ____  ____   __  _____/
     \ \ \    /\    / /    / /\ \       | \ \  | |    | | / /    /
      \ \ \  /  \  / /    / /__\ \      | |\ \ | |    | |/ /    /
       \ \ \/ /\ \/ /    / ______ \     | | \ \| |    | |\ \   /
        \_\  /__\  /____/ /______\ \____| |__\ | |____| |_\ \_/
         \___________________________________________________/
          \                                                 /
           \    Your System Has Been Officically WANKed    /
            \_____________________________________________/
 
     You talk of times of peace for all, and then prepare for war.
 
7. If it has SYSPRV, it disables mail to the SYSTEM account.
 
8. If it has SYSPRV, it modifies the system login command procedure to
APPEAR to delete all of a user's file. (It really does nothing.)
 
9. The program then scans the accounts logical name table for command
procedures and tries to modify the FIELD account to a known password
with login from any source and all privs. This is a primitive virus,
but very effective IF it should get into a privileged account.
 
10. It proceeds to attempt to access other systems by picking node numbers at
random. It then used PHONE to get a list of active users on the remote system.
It proceeds to irritate them by using PHONE to ring them.
 
11. The program then tries to access the RIGHTSLIST file and attempts
to access some remote system using the users found and a list of
"standard" users included with the worm. It looks for passwords
which are the same as that of the account or are blank. It records all
such accounts.
 
12. It looks for an account that has access to SYSUAF.DAT.
 
13. If a priv. account is found, the program is copied to that account and
started. If no priv account was found, it is copied to other accounts found on
the random system.
 
14. As soon as it finishes with a system, it picks another random system and
repeats (forever).
 
Response:
 
1. The following program will block the worm. Extract the following code
and execute it. It will use minimal resources. It create a process named
NETW_BLOCK which will prevent the worm from running.
-------
Editors note:  This fix will work only with this version of the worm.
Mutated worms will require modification of this code; however, this
program should prevent the worm from running long enough to secure
your system from the worms attacks.
-------
==============================================================================
$ Set Default SYS$MANAGER
$ Create BLOCK_WORM.COM
$ DECK/DOLLAR=END_BLOCK
$LOOP:
$ Set Process/Name=NETW_BLOCK
$ Wait 12:0
$ GoTo loop
END_BLOCK
$ Run/Input=SYS$MANAGER:BLOCK_WORM.COM/Error=NL:/Output=NL:/UIC=[1,4] -
    SYS$SYSTEM:LOGINOUT
==============================================================================
 
2. Enable security auditing. The following command turns on the MINIMUM
alarms. The log is very useful in detecting the effects of the virus left by
the worm. It will catch the viruses modification of the UAF.
$ Set Audit/Alarm/Enable=(ACL,Authorization,Breakin=All,Logfailure=All)
 
3. Check for any account with NETWORK access available for blank passwords or
passwords that are the same as the username. Change them!
 
4. If you are running VMS V5.x, get a copy of SYS$UPDATE:NETCONFIG_UPDATE.COM
from any V5.2 system and run it. If you are running V4.x, change the username
and password for the network object "FAL".
 
5. If you have been infected, it will be VERY obvious. Start checking the
system for modifications to the FIELD account. Also, start scanning the system
for the virus. Any file modified will contain the following line:
$ oldsyso=f$trnlnm("SYS$OUTPUT")
It may be in LOTS of command procedures. Until all copies of the virus are
eliminated, the FIELD account may be changed again.
 
6. Once you are sure all of the holes are plugged, you might kill off
NETW_BLOCK. (And then again, maybe not.)
 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 
If you have any technical questions or have an infected system, please
call the CERT:
 
Computer Emergency Response Team
Email: cert@sei.cmu.edu
Telephone: 412-268-7090 (answers 24 hours a day)
 
 
If you have any general questions, please call the SCC:
 
Security Coordination Center
Email: scc@nic.ddn.mil
Telephone: 1-800-235-3155 or 415-859-3695 (7 a.m. to 5 p.m. Pacific time).
 
 
**********************************************************************
DDN Security Bulletin 04         DCA DDN Defense Communications System
23 Oct 89               Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155
 
                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN
 
The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [26.0.0.73 or
10.0.0.51] using login="anonymous" and password="guest".  The bulletin
pathname is SCC:DDN-SECURITY-nn (where "nn" is the bulletin number).
 
**********************************************************************
 
                     HALLOWEEN PRECAUTIONARY NOTE
 
Halloween is traditionally a time  for tricks of all kinds.   In order
to guard against possible benign or malevolent attempts to affect  the
normal operation of your host,  the DDN SCC staff suggests  taking the
following easy precautions:
 
   1. Write a set of emergency procedures for your site and keep it up
      to date.  Address such things as:
 
         - What would you do if you had an intruder (either a human or
           a computer virus)?
 
         - Who would you  call for help?  HINT:  Read the top  of this
           bulletin!  Also, for 24 hour assistance:
 
           MILNET Trouble Desk -- (A/V) 231-1713 or (800) 451-7413
 
         - Who is in charge of security at your site?
 
         - How would you apply a hardware/software fix if needed?
 
   2. Save your files regularly,  and make file  back-ups often.   Put
      the distribution copies of your  software in  a safe  place away
      from your computer room.  Don't forget where they're stored!
 
   3. Avoid trivial passwords and change them often.   (See the "Green
      Book"  (Department  of  Defense  Password Management Guideline),
      CSC-STD-002-85, for information on the use of passwords.)
 
   4. Check  to  make  sure  your  host  has no  unauthorized users or
      accounts.  Also check for obsolete accounts (a favorite path for
      intruders to gain access).
 
   5. Restrict system  ("superuser", "maint", etc.)  privileges to the
      minimum number of accounts you possibly can.
 
   6. Well publicized accounts including "root", "guest", etc. AND the
      personal account  for the  system administrator  should NOT have
      system privileges.   (Past experience  has shown  that these IDs
      are more susceptible to successful intruder attacks.)
 
   7. Keep your maintenance contracts active.
 
Of course,  these steps should be taken throughout the year as part of
your regular operating procedure.
 
**********************************************************************
***********************************************************************
DDN Security Bulletin 90-01       DCA DDN Defense Communications System
25 Jan 90                Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [26.0.0.73 or
10.0.0.51] using login="anonymous" and password="guest".  The bulletin
pathname is SCC:DDN-SECURITY-yy-nn (where "yy" is the year the bulletin
is issued and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-90-01).
**********************************************************************
 
                   SECURITY VIOLATION REPORTING
 

    a.  Initial Notification.  Any DDN user (person/department/agency)
having knowledge of a suspected network security violation must
contact the appropriate Defense Communications Agency OC/ACOC
(Operations Center/Area Communications Operations Center) to report
the violation.  If possible, reporting should be via secure means.

Secure and commercial telephone numbers to DCA Operations Centers are: 

  WESTHEM/CONUS OC has KY3-2222; STU III (DSN) 312-746-1849;
                       (COMM) 202-692-5726/2268 or 1-800-451-7413.

  PACIFIC ACOC has STU III (DSN) 315-456-2777; (COMM) 808-656-2777.  
 
  EUROPEAN ACOC has KY3-6429; STU III (DSN) 314-430-5703; 
                    (COMM) 49-0711-680-5703.  

The SCO or MC supervisor will request the following information:
 
        (1) Identity of caller:
            -What is caller's name and phone number
            -Where is caller calling from (organization)
            -Where is caller calling from (city & state)
            -What is the caller's DDN network address
 
        (2) Details about the incident:
            -When did the violation occur
            -What happened
            -How did the violation occur (if known)
            -What damage was done
            -What has the subscriber done about the violation
            -What networks are they connected to
            -What software is being used - Version
            -How many subscribers are known to be affected
            -How many subscribers are vulnerable (if known)
            -Who else has been notified - Names & phone
             numbers
 
        (3) Anything else the caller wishes to report
 
Once a suspected violation is reported and the above
information collected, the PACIFIC and EUROPEAN ACOCs will
immediately relay this information back to the DCAOC
(WESTHEM/CONUS) for action.
 

    b.  Follow-on Network Information via the Security Coordination
Center.  DCA, through direction provided by the DDN Network Security
Officer (NSO), will provide rapid and reliable follow-on information
on security exposures, fixes, and concerns via the SCC.  Distribution
of information is accomplished via DDN Security Bulletins.  Network
security and management personnel are encouraged to pay close
attention to these bulletins as they may be of great assistance either
in preventing network security problems or in solving existing
problems.  DDN Security Bulletins will be published on as "as needed"
basis.

Note: this bulletin starts a new numbering scheme for DDN Security
Bulletins.  From now on, all bulletin numbers, including those of 
previously issued bulletins, will follow the form YY-NN, where YY is
the year the bulletin is issued and NN is the number of the bulletin 
for that year.  Thus, this is DDN Security Bulletin 90-01; it is 
online at NIC.DDN.MIL as SCC:DDN-SECURITY-90-01.
***********************************************************************
DDN Security Bulletin 90-02      DCA DDN Defense Communications System
30 Jan 90               Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [26.0.0.73 or
10.0.0.51] using login="anonymous" and password="guest".  The bulletin
pathname is SCC:DDN-SECURITY-yy-nn (where "yy" is the year the bulletin
is issued and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-90-01).
**********************************************************************

                      SUN SENDMAIL VULNERABILITY

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

			    CERT Advisory
			   29 January 1990
		      Sun Sendmail Vulnerability


The Computer Emergency Response Team Coordination Center (CERT/CC) has
learned of, and has verified, break-ins on several Internet systems 
in which the intruders have exploited a vulnerability in the Sun
sendmail program.  This vulnerability exists in all versions of
SunOS up to and including the current version, 4.0.3 on Sun 3, Sun 4,
and Sun 386i systems (note that 4.0.2 is the most current version of
SunOS on the 386i machines). That is, all current Sun systems.

The vulnerability has previously been reported to Sun and a solution
to this problem (Sun bug # 1028173) is available via a new version of
sendmail supplied by Sun.  The new sendmail is available directly from
the Sun Answer Center (1-800-USA-4SUN).  Sun 3 and Sun 4 sendmail
binaries are also available via anonymous FTP from uunet.uu.net in the
/sun-fixes directory.

This incident underscores the need for system administrators to
maintain an awareness of the steps their vendors are taking to
improve the security aspects of their products, and to seriously
consider upgrading system configurations when solutions to security
problems are made available.

Administrators of Sun systems are urged to contact Sun for the new
version of the sendmail program.  Administrators of machines other 
than Suns are urged to contact their vendors to verify that they are 
running the latest version of sendmail, since there may have been 
security related fixes to it in the past year.

If you need further information on this problem, contact your Sun
representative or CERT/CC.  CERT/CC can be contacted by telephone at
(412) 268-7090 (24 hours) or email to cert@cert.sei.cmu.edu (monitored
daily).

Our thanks to Matt Bishop and Wayne Cripps for their efforts in
analyzing and investigating this problem and its solution.


Kenneth R. van Wyk
Technical Coordinator, Computer Emergency Response Team
Software Engineering Institute
Carnegie Mellon University
cert@CERT.SEI.CMU.EDU
(412) 268-7090  (24 hour hotline)

***********************************************************************
DDN Security Bulletin 90-03       DCA DDN Defense Communications System
15 Feb 90                Published by: DDN Security Coordination Center
Obsoletes Sec. Bull. 90-01            (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [26.0.0.73 or
10.0.0.51] using login="anonymous" and password="guest".  The bulletin
pathname is SCC:DDN-SECURITY-yy-nn (where "yy" is the year the bulletin
is issued and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-90-01).
**********************************************************************
 
                   SECURITY VIOLATION REPORTING
 
---------------------------------------------------------------------
This bulletin replaces DDN Security Bulletin 90-01 and provides
corrections to that bulletin.  Please destroy bulletin 90-01 and
use the guidelines in this version of the bulletin for reporting
security problems.
---------------------------------------------------------------------


    a.  Initial Notification.  Any DDN user (person/department/agency)
having knowledge of a suspected network security violation must
contact the appropriate Defense Communications Agency OC/ACOC
(Operations Center/Area Communications Operations Center) MILNET
Monitoring Center to report the violation.  If possible, reporting
should be via secure means.

Secure and commercial telephone numbers to DCA Operations Centers are: 

  WESTHEM/CONUS OC has KY3-2222; STU III (DSN) 312-746-1849;
                       (COMM) 202-692-5726/2268 or 1-800-451-7413.

  PACIFIC ACOC has STU III (DSN) 315-456-2777; (COMM) 808-656-2777.  
 
  EUROPEAN ACOC has KY3-6429; STU III (DSN) 314-430-5244; 
                    (COMM) 49-0711-680-5703.  

The Monitoring Center supervisor will request the following information:
 
        (1) Identity of caller:
            -What is caller's name and phone number
            -Where is caller calling from (organization)
            -Where is caller calling from (city & state)
            -What is the caller's DDN network address
 
        (2) Details about the incident:
            -When did the violation occur
            -What happened
            -How did the violation occur (if known)
            -What damage was done
            -What has the subscriber done about the violation
            -What networks are they connected to
            -What software is being used - Version
            -How many subscribers are known to be affected
            -How many subscribers are vulnerable (if known)
            -Who else has been notified - Names & phone
             numbers
            -Does caller have any idea as to the identity of the 
             intruder/violator
 
        (3) Anything else the caller wishes to report
 
Once a suspected violation is reported and the above
information collected, the PACIFIC and EUROPEAN ACOCs will
immediately relay this information back to the DCAOC
(WESTHEM/CONUS) for action.
 

    b.  Follow-on Network Information via the Security Coordination
Center.  DCA, through direction provided by the DDN Network Security
Officer (NSO), will provide rapid and reliable follow-on information
on security exposures, fixes, and concerns via the SCC.  Distribution
of information is accomplished via DDN Security Bulletins.  Network
security and management personnel are encouraged to pay close
attention to these bulletins as they may be of great assistance either
in preventing network security problems or in solving existing
problems.  DDN Security Bulletins will be published on as "as needed"
basis.
***********************************************************************
DDN Security Bulletin 90-05      DCA DDN Defense Communications System
20 Mar 90                Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [26.0.0.73]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yy-nn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-90-01).
**********************************************************************


+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +


			    CERT Advisory
			    March 19, 1990
		      Internet Intruder Warning

There have been a number of media reports stemming from a March 19 New
York Times article entitled 'Computer System Intruder Plucks Passwords
and Avoids Detection.'  The article referred to a program that
attempts to get into computers around the Internet.

At this point, the Computer Emergency Response Team Coordination
Center (CERT/CC) does not have hard evidence that there is such a
program.  What we have seen are several persistent attempts on systems
using known security vulnerabilities.  All of these vulnerabilities
have been previously reported.  Some national news agencies have
referred to a 'virus' on the Internet; the information we have now
indicates that this is NOT true.  What we have seen and can confirm is
an intruder making persistent attempts to get into Internet systems.

It is possible that a program may be discovered.  However, all the
techniques used in these attempts have also been used, in the past, by
intruders probing systems manually.

As of the morning of March 19, we know of several systems that have
been broken into and several dozen more attempts made on Thursday and
Friday, March 15 and 16.

Systems administrators should be aware that many systems around the
Internet may have these vulnerabilities, and intruders know how to
exploit them.  To avoid security breaches in the future, we recommend
that all system administrators check for the kinds of problems noted
in this message.

The rest of this advisory describes problems with system
configurations that we have seen intruders using.  In particular, the
intruders attempted to exploit problems in Berkeley BSD derived UNIX
systems and have attacked DEC VMS systems.  In the advisory below,
points 1 through 12 deal with Unix, points 13 and 14 deal with the VMS
attacks.

If you have questions about a particular problem, please get
in touch with your vendor.

The CERT makes copies of past advisories available via anonymous FTP
(see the end of this message).  Administrators may wish to review
these as well.

We've had reports of intruders attempting to exploit the following
areas:


1) Use TFTP (Trivial File Transfer Protocol) to steal password files.  

   To test your system for this vulnerability, connect to your system
using TFTP and try 'get /etc/motd'.  If you can do this, anyone else
can get your password file as well.  To avoid this problem, disable
tftpd.

   In conjunction with this, encourage your users to choose passwords
that are difficult to guess (e.g. words that are not contained in any
dictionary of words of any language; no proper nouns, including names
of "famous" real or imaginary characters; no acronyms that are common
to computer professionals; no simple variations of first or last
names, etc.)  Furthermore, inform your users not to leave any clear
text username/password information in files on any system.

   If an intruder can get a password file, he/she will usually take it
to another machine and run password guessing programs on it. These
programs involve large dictionary searches and run quickly even on slow
machines.  The experience of many sites is that most systems that do
not put any controls on the types of passwords used probably have at
least one password that can be guessed.


2) Exploit accounts without passwords or known passwords (accounts
with vendor supplied default passwords are favorites).  Also uses
finger to get account names and then tries simple passwords.  

   Scan your password file for extra UID 0 accounts, accounts with no
password, or new entries in the password file.  Always change vendor
supplied default passwords when you install new system software.


3) Exploit holes in sendmail.

   Make sure you are running the latest sendmail from your vendor.
BSD 5.61 fixes all known holes that the intruder is using.  


4) Exploit bugs in old versions of FTP; exploit mis-configured
   anonymous FTP

   Make sure you are running the most recent version of FTP which is
the Berkeley version 4.163 of Nov.  8 1988.  Check with your vendor
for information on configuration upgrades.  Also check
your anonymous FTP configuration.  It is important to follow the
instructions provided with the operating system to properly configure
the files available through anonymous ftp (e.g., file permissions,
ownership, group, etc.).  Note especially that you should not use your
system's standard password file as the password file for FTP.


5) Exploit the fingerd hole used by the Morris Internet worm.

   Make sure you're running a recent version of finger.  Numerous
Berkeley BSD derived versions of UNIX were vulnerable.


Some other things to check for:

6) Check user's .rhosts files and the /etc/hosts.equiv files for systems
outside your domain.  Make sure all hosts in these files are
authorized and that the files are not world-writable.


7) Examine all the files that are run by cron and at.  We've seen
intruders leave back doors in files run from cron or submitted to at.
These techniques can let the intruder back on the system even after
you've kicked him/her off.  Also, verify that all files/programs
referenced (directly or indirectly) by the cron and at jobs, and the
job files themselves, are not world-writable.


8) If your machine supports uucp, check the L.cmds file to see if
they've added extra commands and that it is owned by root (not by uucp!)
and world-readable.  Also, the L.sys file should not be world-readable
or world-writable.


9) Examine the /usr/lib/aliases (mail alias) file for unauthorized
entries.  Some alias files include an alias named 'uudecode'; if this
alias exists on your system, and you are not explicitly using it, then
it should be removed.


10) Look for hidden files (files that start with a period and are
normally not shown by ls) with odd names and/or setuid capabilities,
as these can be used to "hide" information or privileged (setuid root)
programs, including /bin/sh.  Names such as '..  ' (dot dot space
space), '...', and .xx have been used, as have ordinary looking names
such as '.mail'.  Places to look include especially /tmp, /usr/tmp,
and hidden directories (frequently within users' home directories).


11) Check the integrity of critical system programs such as su, login,
and telnet.  Use a known, good copy of the program, such as the
original distribution media and compare it with the program you are
running.


12) Older versions of systems often have security vulnerabilities that
are well known to intruders.  One of the best defenses against
problems is to upgrade to the latest version of your vendor's system.


VMS SYSTEM ATTACKS:

13) The intruder exploits system default passwords that have not been
changed since installation.  Make sure to change all default passwords
when the software is installed.  The intruder also guesses simple user
passwords.  See point 1 above for suggestions on choosing good
passwords.

14) If the intruder gets into a system, often the programs
loginout.exe and show.exe are modified.  Check these programs against
the files found in your distribution media.


Past advisories and other information are available for anonymous ftp
From cert.sei.cmu.edu (128.237.253.5).

------------------------------------------------------------------------------

If you believe that your system has been compromised, contact the
Defense Communications Agency DDN/MILNET Monitoring Center and CERT
via telephone or email.

MILNET Monitoring Center
Telephone: 800-451-7413 or 202-692-5726 (commercial)
           312-746-1849 (DSN)


CERT
Internet: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline
***********************************************************************
DDN Security Bulletin 90-06      DCA DDN Defense Communications System
27 Mar 90               Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [26.0.0.73]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yy-nn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-90-01).
**********************************************************************

                          PRECAUTIONARY NOTE
 
April Fools' day (April 1) has traditionally been a time for pranks of
all kinds.  In order to guard against possible benign or malevolent
attempts to affect the normal operation of your host, we suggest taking
the following easy precautions:
 
 
   1. Write a set of emergency procedures for your site and keep it up
      to date.  Refer to DDN Security Bulletin 90-03 for help regarding
      the type of information to collect and whom to call.
 
   2. Save your files regularly, and make file  back-ups often.   Put
      the distribution copies of your  software in  a safe  place away
      from your computer room.  Don't forget where they're stored!
 
   3. Avoid trivial passwords and change them often.   (See the "Green
      Book"  (Department  of  Defense  Password Management Guideline),
      CSC-STD-002-85, for information on the use of passwords.)
 
   4. Check  to  make  sure  your  host  has no  unauthorized users or
      accounts.  Also check for obsolete accounts (a favorite path for
      intruders to gain access).
 
   5. Restrict system  ("superuser", "maint", etc.)  privileges to the
      minimum number of accounts you possibly can.
 
   6. Well publicized accounts including "root", "guest", etc., having
      system privileges should be renamed to avoid undue attention.
 
   7. Keep your maintenance contracts active.
 
Of course,  these steps should be taken throughout the year as part of
your regular operating procedures.
DDN Security Bulletin 90-07      DCA DDN Defense Communications System
9 Apr 90                Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.67.67.20]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yy-nn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-90-01).
**********************************************************************

            FEDERAL INFORMATION PROCESSING STANDARDS
                        AVAILABLE ONLINE 


Five Federal Information Processing Standards (FIPS) publications
are available online at the Security Coordination Center (SCC).
These documents address various aspects of computer and network
security.  FIPS 500-166 is a guide regarding managing the threat
of computer viruses or intrustions.  Also available are the
executive, management, and user guides regarding methods to
protect information resources.

You can obtain these files on the NIC.DDN.MIL host [192.67.67.20] via
anonymous FTP or Kermit.  You can also get them via e-mail by sending
a message to SERVICE@NIC.DDN.MIL with the subject line reading 
SEND SCC:FIPS_500_###.TXT (replace the ### with the number of the file you
want and end with .PS instead of .TXT for the postscript version of
FIPS 500-166).  If you have questions about the procedures for
obtaining copies of these files, please call 1-800-235-3155 or send a
message to SCC@NIC.DDN.MIL.

Below are the file names as they are online and the descriptive titles
of the documents.  Use the file name, rather than the document title,
when requesting the file online.  All files are in the "SCC:" directory.


File Name                   Document Title

FIPS_500_166.TXT............COMPUTER VIRUSES AND RELATED THREATS: A
                            MANAGEMENT GUIDE (SEP-89)
FIPS_500_166.PS.............COMPUTER VIRUSES AND RELATED THREATS: A
                            MANAGEMENT GUIDE - POSTSCRIPT VERSION
FIPS_500_169.TXT............EXECUTIVE GUIDE TO THE PROTECTION OF
                            INFORMATION RESOURCES (OCT-89)
FIPS_500_170.TXT............MANAGEMENT GUIDE TO THE PROTECTION OF
                            INFORMATION RESOURCES (OCT-89)
FIPS_500_171.TXT............COMPUTER USER'S GUIDE TO THE PROTECTION OF
                            INFORMATION RESOURCES (OCT-89)

***********************************************************************
DDN Security Bulletin 9009       DCA DDN Defense Communications System
16 Aug 90               Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.67.67.20]
using login="anonymous" and password="guest".  The bulletin
pathname is SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin
is issued and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9001).
**********************************************************************

                    SunView selection_svc vulnerability 

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +


CA-90:05                       CERT Advisory
                              August 14, 1990
                    SunView selection_svc vulnerability 

Sun has recently released a patch for a security hole in SunView.
This problem affects SunView running on all versions of SunOS (3.5 and
before, 4.0, 4.0.1, 4.0.3, and 4.1) and all platforms (Sun3, Sun4,
386i).  This vulnerability allows any remote system to read selected
files from the workstation running SunView.  As noted below in the
IMPACT section, the files that can be read are limited.

This vulnerability is in the SunView (aka SunTools) selection_svc
facility and can be exploited while SunView is in use; however, as
noted below in the IMPACT section, this bug may be exploitable after
the user quits using Sunview.  This problem cannot be exploited while
X11 is in use (unless the user runs X11 after running Sunview; see the
IMPACT section).  This problem is specific to Sun's SunView software;
to our knowledge, this problem does NOT affect other vendor platforms
or software.

OBTAINING THE PATCH

To obtain the patch, please call your local Sun Answer Center
(in the USA, it's 1-800-USA-4SUN), and ask for patch number 100085-01.
You can also reference Sun Bug ID 1039576.

The patch is available for SunOS 4.0.1, 4.0.3 and SunOS 4.1, on Sun3,
Sun4, and 386i architectures.  Contact Sun for further details.


IMPACT

On Sun3 and Sun4 systems, a remote system can read any file that is
readable to the user running SunView.  On the 386i, a remote system
can read any file on the workstation running SunView regardless of
protections.  Note that if root runs Sunview, all files are
potentially accessible by a remote system.

If the password file with the encrypted passwords is world readable,
an intruder can take the password file and attempt to guess passwords.
In the CERT/CC's experience, most systems have at least one password
that can be guessed.

Sunview does not kill the selection_svc process when the user quits
>From Sunview.  Thus, unless the process is killed, remote systems can
still read files that were readable to the last user that ran Sunview.
Under these circumstances, once a user has run Sunview, start using
another window system (such as X11), or even logoff, but still have
files accessible to remote systems.  However, even though
selection_svc is not killed when Sunview exits, the patch still solves
the security problem and prevents remote access.


CONTACT INFORMATION

For further questions, please contact your Sun answer center or send
mail to security-features@sun.com.

Thanks to Peter Shipley for discovering, documenting, and helping
resolve this problem.
-----------------------------------------------------------------------------

J. Paul Holbrook
Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Internet: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline: CERT personnel answer
           7:30a.m.-6:00p.m. EST, on call for
           emergencies other hours.

Past advisories and other information are available for anonymous ftp
From cert.sei.cmu.edu (128.237.253.5).
***********************************************************************
DDN Security Bulletin 9010       DCA DDN Defense Communications System
16 Aug 90               Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.67.67.20]
using login="anonymous" and password="guest".  The bulletin
pathname is SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin
is issued and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9001).
**********************************************************************

        Sun Microsystems Customer Warning System Established


The below information is an announcement by Sun Microsystems that Sun
has established a Customer Warning System to handle computer security
incidents and their prevention.  In addition, the announcement
describes the characteristics of the warning system and the methods
Sun customers should use to report problems and receive Sun security
warnings.



From: Beverly Ulbrich - Product Manager, Software Security
      Jack Collins - Director, Technical Support Services

Subject:  Announcing Sun Microsystem's Customer Warning System 
                   for Security Incident Handling  

Date:   August 14, 1990


In order to best serve our customers' service needs, Sun has established a 
Customer Warning System (CWS) for handling security incidents.  This is a 
formal process which includes:
	- Having a well advertised point of contact in Sun for reporting 
	  security problems. 			
	- Pro-actively alerting customers of worms, viruses or other security 
	  holes that could affect their systems. 
	- Distributing the patch (and/or work-around) to our customers as 
	  quickly as possible.

More specifically, the CWS is being set up as follows:

We have created an email address ( security-alert@sun.com ) which will enable 
both internal and external people to have a single place to report security 
problems.  We have provided a voice-mail back-up ( (415)-336-7205 ) for the 
cases where sending email is not possible.   *ALL* SECURITY HOLES SHOULD BE 
REPORTED TO THIS ALIAS.

We have filled the position of "Security Coordinator" in our Customer Service 
Organization.  The Security Coordinator is responsible for manning the email 
and voice mail hotlines and evaluating the security problems.   We have a 
Customer Warning System "SWAT Team" in place to address severe security 
incidents.  The CWS SWAT Team consists of knowledgeable senior people within 
Sun Corporate who are committed to being available to meet whenever required 
and who are empowered to make all necessary decisions.  

We plan on publicizing the CWS bi-monthly to the allsun alias.  It will 
also be announced (and supported) by the various Computer Emergency Response 
Teams Sun works with.  Please pass this information along to whoever you 
feel is appropriate.  Sales Representatives should be certain to send this 
information to all their security-conscious customers!

Customers and Sun Field Offices may send us a "Security Contact" from their
organizations.  This is the person Sun should contact in the case of any 
new security problems.  He or she will be sent information on the problem at 
hand, including work-arounds and how and when to obtain fixes.  Preferably, 
your Security Contact should be technical.  He or she should be your site's 
System Administrator (or System Security Administrator).  The information we 
need for the Security Contact from the three geographies for customers is as 
follows:

---------------------- U.S. Security Contact Information --------------------

Company Name:
Security Contact's Name:
Customer Number (from Cullinet):
Address ID (from Cullinet)*:

Postal address: 
Email address: 
Phone number:
Fax number: 
Preferred method of contact (from above: 1st, 2nd and 3rd choice):


* If there is not an existing Address ID, we need the full address for
  the security contact.



----------------- Europe and ICON Security Contact Information ---------

Company Name:
Security Contact's Name:
Customer Number:
Address Id:
If there is no customer number or Address ID, then we need the following
information for each customer:

Postal Address:
Email Address:
Phone Number:
Fax Number:
Preferred method of contact (from above: 1st, 2nd and 3rd choice):


--------------- Sun Field Office Security Contact Information ---------------

Office Location:
Security Contact's Name*:
Email address:

*One per office


----------------------------------------------------------------------------


*****   PLEASE SEND THIS INFORMATION TO:   *****

 	  security-alert@sun.com
  
or, if you prefer postal mail:

	Brad Powell
	c/o Sun Microsystems
	MTV18-04
	2550 Garcia Ave.
	Mt. View, CA 94043


All questions should be sent to bju@sun.com.
***********************************************************************
DDN Security Bulletin 9011       DCA DDN Defense Communications System
3 Oct 90                Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.67.67.20]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9001).
**********************************************************************

                  NeXT's System Software: Four Problems

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +


------------------------------------------------------------------------------
CA-90:06                       CERT Advisory
			      October 2, 1990
                          NeXT's System Software

-----------------------------------------------------------------------------
This message is to alert administrators of NeXT Computers of four
potentially serious security problems.

The information contained in this message has been provided by David Besemer,
NeXT Computer, Inc.  The following describes the four security problems,
NeXT's recommended solutions and the known system impact.

------------------------------------------------------------------------------

  Problem #1 DESCRIPTION:  On Release 1.0 and 1.0a a script exists in
  /usr/etc/restore0.9 that is a setuid shell script.  The existence of  
  this script is a potential security problem.

  Problem #1 IMPACT:  The script is only needed during the installation
  process and isn't needed for normal usage.  It is possible for any
  logged in user to gain root access.

  Problem #1 SOLUTION:  NeXT owners running Release 1.0 or 1.0a should  
  remove /usr/etc/restore0.9 from all disks.  This file is installed by  
  the "BuildDisk" application, so it should be removed from all systems  
  built with the standard release disk, as well as from the standard  
  release disk itself (which will prevent the file from being installed  
  on systems built with the standard release disk in the future).  You  
  must be root to remove this script, and the command that will remove  
  the script is the following:

  # /bin/rm /usr/etc/restore0.9

                                    ---

  Problem #2 DESCRIPTION:  On NeXT computers running Release 1.0 or
  1.0a that also have publicly accessible printers, users can gain
  extra permissions via a combination of bugs.
  
  Problem #2 IMPACT:  Computer intruders are able to exploit this security
  problem to gain access to the system.  Intruders, local users and remote
  users are able to gain root access.

  Problem #2 SOLUTION:  NeXT computer owners running Release 1.0 or  
  1.0a should do two things to fix a potential security problem.   
  First, the binary /usr/lib/NextPrinter/npd must be replaced with a  
  more secure version.  This more secure version of npd is available  
  through your NeXT support center.  Upon receiving a copy of the more  
  secure npd, you must become root and install it in place of the old  
  one in /usr/lib/NextPrinter/npd.  The new npd binary needs to be  
  installed with the same permission bits (6755) and owner (root) as  
  the old npd binary.  The commands to install the new npd binary are  
  the following:
  
  # /bin/mv /usr/lib/NextPrinter/npd /usr/lib/NextPrinter/npd.old
  # /bin/mv newnpd /usr/lib/NextPrinter/npd
	  (In the above command, "newnpd" is the npd binary
	  that you obtained from your NeXT support center.)
  # /etc/chown root /usr/lib/NextPrinter/npd
  # /etc/chmod 6755 /usr/lib/NextPrinter/npd
  
  The second half of the fix to this potential problem is to change the  
  permissions of directories on the system that are currently owned and  
  able to be written by group "wheel".  The command that will remove  
  write permission for directories owned and writable by group "wheel"  
  is below.  This command is all one line, and should be run as root.
  
  # find / -group wheel ! -type l -perm -20 ! -perm -2 -ls -exec chmod  
  g-w {} \; -o -fstype nfs -prune

                                    ---

  Problem #3 DESCRIPTION:  On NeXT computers running any release of the
  system software,  public access to the window server may be a
  potential security problem.

  The default in Release 1.0 or 1.0a is correctly set so that public access
  to the window server is not available.  It is possible, when upgrading from
  a prior release, that the old configuration files will be reused.  These
  old configuration files could possibly enable public access to the window
  server.

  Problem #3 IMPACT:  This security problem will enable an intruder to gain
  access to the system.

  Problem #3 SOLUTION:  If public access isn't needed, it should be disabled.

  1. Launch the Preferences application, which is located in /NextApps
  2. Select the UNIX panel by pressing the button with the UNIX
     certificate on it.
  3. If the box next to Public Window Server contains a check, click on
     the box to remove the check.

                                    ---

  Problem #4 DESCRIPTION: On NeXT computers running any release of the
  system software, the "BuildDisk" application is executable by all users.

  Problem #4 IMPACT:  Allows a user to gain root access.

  Problem #4 SOLUTION: Change the permissions on the "BuildDisk" application
  allowing only root to execute it.  This can be accomplished with the
  command:

  # chmod 4700 /NextApps/BuildDisk

  To remove "BuildDisk" from the default icon dock for new users, do the
  following:

  1. Create a new user account using the UserManager application.
  2. Log into the machine as that new user.
  3. Remove the BuildDisk application from the Application Dock by dragging
     it out.
  4. Log out of the new account and log back in as root.
  5. Copy the file in ~newuser/.NeXT/.dock to /usr/template/user/.NeXT/.dock
	(where ~newuser is the home directory of the new user account)
  6. Set the protections appropriately using the following command:
        # chmod 555 /usr/template/user/.NeXT/.dock
  7. If you wish, with UserManager, remove the user account that you created
     in step 1.

  In release 2.0, the BuildDisk application will prompt for the root password
  if it is run by a normal user.

-----------------------------------------------------------------------------
CONTACT INFORMATION
 
For further questions, please contact your NeXT support center.

NeXT has also reported that these potential problems have been fixed in
NeXT's Release 2.0, which will be available in November, 1990.

Thanks to Corey Satten and Scott Dickson for discovering, documenting, and
helping resolve these problems.

-----------------------------------------------------------------------------
Edward DeHart
Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline: CERT personnel answer
           7:30a.m.-6:00p.m. EST, on call for
           emergencies other hours.

Past advisories and other information are available for anonymous ftp
from cert.sei.cmu.edu (128.237.253.5).


***********************************************************************
DDN Security Bulletin 9013       DCA DDN Defense Communications System
13 NOV 90               Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.67.67.20]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9001).
**********************************************************************

			  VAX/VMS Break-Ins

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +


CA-90:09                    CERT Advisory
                          November 8, 1990
			  VAX/VMS Break-ins

DESCRIPTION:
 
     Several VAX/VMS systems are presently being subjected to
intrusions by a persistent intruder(s).  The intruder utilizes DECnet,
TCP/IP, and/or X25 access paths to gain unauthorized entry into
accounts (privileged and non-privileged).  Once a privileged account
is breached, the intruder disables auditing & accounting and installs
a trojan horse image on the system.  In the most recent attacks, the
intruder has installed the image VMSCRTL.EXE in SYS$LIBRARY.  (Note
that VMSCRTL.EXE is not a vendor-supplied filename.) The command
procedure DECW$INSTALL_LAT.COM is placed in SYS$STARTUP and installs
the image.  Note that these images and command files are sufficiently
camouflaged so as to appear to be valid VMS system files, even upon
close inspection.

     There is no evidence that the intruder is exploiting any system 
vulnerability to gain access to the affected systems.  The  intruder 
uses valid username/password combinations to gain access to accounts.
The intruder most likely obtains these username/password combinations 
by systematically searching through text files on the user disks of 
penetrated systems for clear-text username/password pairs.  These 
username/password combinations are often valid on remote systems, 
which allows the intruder to access them as well.  Once a privileged 
account is accessed, the intruder will use the AUTHORIZE utility to 
detect and exploit dormant accounts (especially dormant privileged 
accounts).  The intruder has also assigned privileges to dormant 
non-privileged accounts.

 
IMPACT: 

Unauthorized users who gain privileged and/or non-privileged system
access might deliberately or inadvertently affect the integrity of
system information and/or affect the integrity of the computing
resource.  
 
 
SOLUTION:

The following steps are recommended for detecting whether systems at
your site have been compromised:

     1.  Search for SYS$LIBRARY:VMSCRTL.EXE and
SYS$STARTUP:DECW$INSTALL.COM.  (This can be done with the following
DCL command: $ DIR device:[*...]/SINCE=date /MODIFIED).  Note that to
call the command procedure which installs the image, the intruder will
utilize SYSMAN to modify SYS$STARTUP:VMS$LAYERED.DAT.  Thus, there
will be an unexplained modification to SYS$STARTUP:VMS$LAYERED.DAT.
This may be the surest indication of an intrusion, since the intruder
could easily change the names and locations of the trojan horse image
and its accompanying command procedure.

     2.  If you discover that auditing or accounting has been disabled
for a period of time, go into AUTHORIZE and ensure that no password or
other changes were made during that time.  Password changes while
auditing and accounting have been disabled may indicate unauthorized
access into your system.


     The following pre-emptive actions are suggested:

     1. DISUSER all dormant accounts, especially dormant privileged
accounts.

     2. Advise all users of the security problems inherent in placing
username/password combinations in text files.  Consider searching your
user disks for such occurrences.

     3. Change all vendor-supplied default passwords (e.g., MAILER,
DECNET, SYSTEM) and make sure all passwords are difficult to guess.

     4. Make sure that all privileged users have only the minimum
privileges that are REQUIRED to perform their current tasks.

     5. Closely monitor all relevant audit trails.

-------------------------------------------------------------------------
 
Kenneth R. van Wyk
Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
 
Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline: CERT personnel answer
           7:30a.m.-6:00p.m. EST, on call for
           emergencies other hours.
 
Past advisories and other information are available for anonymous ftp
from cert.sei.cmu.edu (128.237.253.5).



***********************************************************************
DDN Security Bulletin 9109       DCA DDN Defense Communications System
23 July 91              Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.67.67.20]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9001).
**********************************************************************

                   Patch for SunOS /usr/etc/rpc.mountd

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +


CA-91:09                        CERT Advisory
                                July 15, 1991
                     Patch for SunOS /usr/etc/rpc.mountd

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning the availability of a security patch 
for /usr/etc/rpc.mountd in Sun Microsystems, Inc. operating systems.  
This problem will be fixed in SunOS 5.0.  Patches are available for
SunOS 4.1, and SunOS 4.1.1 through your local Sun answer centers 
worldwide as well as through anonymous ftp to ftp.uu.net (in ~ftp/sun-dist).
Patch ID and file information are as follows:

Fix                     Patch ID       Filename            Checksum
/usr/etc/rpc.mountd	100296-01      100296-01.tar.Z     01501   233

Please note that Sun Microsystems sometimes updates patch files.  If
you find that the checksum is different please contact Sun Microsystems
or us for verification.
---------------------------------------------------------------------------
    
I.   DESCRIPTION:

     If an access list of hosts within /etc/exports is a string 
     over 256 characters then the filesystem can be mounted by 
     everyone.
      
II.  IMPACT:

     Unauthorized remote hosts will be able to mount the filesystem.

III. SOLUTION:

     As root:

     1.  Move the existing rpc.mountd aside

         # mv /usr/etc/rpc.mountd /usr/etc/rpc.mountd.OLD

     2.  Install the new version

         # cp sun{3,3x,4,4c}/{4.1,4.1.1,4.1_PSR_A}/rpc.mountd /usr/etc
         # chown root.staff /usr/etc/rpc.mountd
         # chmod 755 /usr/etc/rpc.mountd

     3.  Kill the currently running rpc.mountd and restart it, or,
         reboot the system.  Systems currently mounting filesystems
         from this host will have interruptions in service either
         way.  

---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC via
telephone or e-mail.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:
           CERT/CC personnel answer 7:30a.m.-6:00p.m. EST,
           on call for emergencies during other hours.

Past advisories and other computer security related information are available
for anonymous ftp from the cert.sei.cmu.edu (192.88.209.5) system.
***********************************************************************
DDN Security Bulletin 9101       DCA DDN Defense Communications System
21 Feb 91               Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.67.67.20]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9001).
**********************************************************************

                     SunOS /bin/mail Vulnerability

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +


CA-91:01                       CERT Advisory
                             February 21,  1991
                        SunOS /bin/mail Vulnerability

-------------------------------------------------------------------------
The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received the following information from Sun Microsystems.  Sun Microsystems
has given the CERT/CC permission to distribute their Security Bulletin.
It contains information regarding a fix for a vulnerability in SunOS 4.0.3,
SunOS 4.1 and SunOS 4.1.1.

For more information, please contact Sun Microsystems at 1-800-USA-4SUN.

-------------------------------------------------------------------------

SUN MICROSYSTEMS SECURITY BULLETIN:
#00105

This information is only to be used for the purpose of alerting
customers to problems. Any other use or re-broadcast of this
information without the express written consent of Sun Microsystems
shall be prohibited.

Sun expressly disclaims all liability for any misuse of this information
by any third party.
============================================================================

All of these patches are available through your local Sun answer centers
worldwide. As well as through anonymous ftp to ftp.uu.net in the
~ftp/sun-dist directory.

Please refer to the Sun BugID and PatchID when requesting patches from Sun
answer centers.
 
NO README information will be posted in the patch on UUNET. Please refer
the the information below for patch installation instructions.
============================================================================
 
Sun Bug ID  : 1047340
Synopsis    : /bin/mail can be caused to invoke a root shell if given the
              (im)proper arguments.
Sun Patch ID: 100224-01
Checksum of compressed tarfile 100224-01.tar.Z = 64102   109
 
============================================================================

Patch-ID#  100224-01
Keywords: mail, delivery, /bin/mail, 4.1, sendmail
Synopsis: SunOS 4.1.1, 4.1,  4.0.3: program "mail" problem in delivering
          mail + security enhancement
Date: 15 Jan 1990
 
SunOS release: 4.0.3 4.1 4.1.1

Topic:  /bin/mail delivering fix
 
BugId's fixed with this patch: 1045636 1047340

Architectures for which this patch is available: sun3, sun3x, sun4, sun4c,
sun4/490_4.1_PSR_A.

Patches which may conflict with this patch: 100161-01. This patch obsoletes
					    patch 100161-01 since this patch
					    incorporates 100161-01 fixes plus
					    the new fixes.
Obsoleted by: SysV Release 4

Problem Description:

Bug ID: 1045636

 /bin/mail is the local delivery agent for sendmail.  In
some particular instance, /bin/mail parse its argument incorrectly
and therefore, mail are being drop into the bit bucket...

If you have users that has "f" has the second character, you might want
to try the following: (substitute "af" with anyuser with "f" as second
character)

From any machine except mailhost:

/bin/lib/sendmail -t -v <<END
From: anyuser
to: anyuser
Subject: test
Cc: af          <-- substitute any username with second character as "f"
test

END

When the mail arrived on mailhost, sendmail process will invoke
/bin/mail with the following argument "/bin/mail -r anyuser -d af
anyuser".  Now you are in trouble.  The following are different
scenarios for /bin/mail.

1) /bin/mail -r anyuser -d af  <mailmessages            worked fine
2) /bin/mail -r anyuser -d anyone af ... <mailmessages  worked fine
3) /bin/mail -r anyuser -d af anyone ... <mailmessages  !!error!!

    in case (3), /bin/mail thinks that you want to read mail instead of
    delivering mail.  Therefore, mail messages is lost.

 
BugID: 1047340

/bin/mail can be caused to invoke a root shell if given the
        (im)proper arguments.  

INSTALL:

AS ROOT:
 
# mv /bin/mail to /bin/mail.old
# cp $arch/$os/mail to /bin/mail
 (where $arch is either sun3 sun4 sun4c or sun3x)
 (and where $os is either 4.0.3 4.1 or 4.1.1)
 ( change the permissions for the newly installed mail)
# chmod 4755 /bin/mail

-------------------------------------------------------------------------

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:
           CERT personnel answer 7:30a.m.-6:00p.m. EST.
           On call for emergencies during other hours.

Past advisories and other computer security related information are available
for anonymous ftp from the cert.sei.cmu.edu (128.237.253.5) system.

Organization:  National Institute of Standards and Technology (NIST)
Sub-Organization:  National Computer Systems Laboratory
 



***********************************************************************
DDN Security Bulletin 9103       DCA DDN Defense Communications System
27 Mar 91               Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.67.67.20]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9001).
**********************************************************************

                    Patch Available for SunOS in.telnetd


+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Incident Advisory Capability (CIAC) and is being relayed unedited !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +



                           NO RESTRICTIONS
        _____________________________________________________
             The Computer Incident Advisory Capability
                         ___  __ __    _     ___
                        /       |     / \   /
                        \___  __|__  /___\  \___
        _____________________________________________________
                         Information Bulletin

March 26, 1991, 1330 PST                                     Number B-20

                    Patch Available for SunOS in.telnetd
________________________________________________________________________
PROBLEM:  SunOS versions 4.0.3 through 4.1.1 in.telnetd exhibits may
          send output to an authorized user.  
PLATFORM: All Sun3 and Sun4 computers running SunOS 4.0.3, 4.1 or
          4.1.1.  
DAMAGE:   May allow unauthorized access to the system.
SOLUTIONS:  Patch/update available from Sun.  
IMPACT OF PATCH:  Vulnerability eliminated.  No other side-effects
          reported.
_______________________________________________________________________
		 Critical Information about in.telnetd Patch

Sun Microsystems has recently announced the availability of a new patch
for the utility in.telnetd (the daemon that controls the remote login
program, telnet).  If not patched this utility may allow unauthorized
access to systems.  The patch is available from Sun Microsystems as
Patch ID# 100125-02 (this number is required to order this patch from
the Sun Answer Center).  This patch is also available via anonymous ftp
at uunet.uu.net (IP# 192.48.96.2) in the file
sun-dist/100125-02.tar.Z.  If you obtain the patch using anonymous ftp,
no additional installation instructions are necessary.  If you obtain
the patch in some other manner (e.g., from CIAC), we suggest that you
use the following installation procedure:

1.	Log in as root on the system to be repaired.

2.	Disable the flawed version of in.telnetd with the following 
commands:

	# mv /usr/etc/in.telnetd /usr/etc/in.telnetd.FCS
	# chmod 600 /usr/etc/in.telnetd.FCS

3.	Obtain the patch file 100125-02.tar.Z (either from Sun or a trusted 
anonymous FTP site such as uunet.uu.net).

4.	Uncompress the patch file:

	# uncompress 100125-02.tar.Z

5.      Extract the patch file appropriate to your architecture (either
3, 3x, 4, or 4c -- contact your Sun representative if you do not know
which architecture you have)

	# tar xf 100125-02.tar {architecture}/in.telnetd
	where {architecture} is one of 3, 3x, 4, or 4c.

6.      Copy the patch file to the appropriate directory, and set the
ownership and permissions of the utility:

	# cp {architecture}/in.telnetd /usr/etc/in.telnetd
	# chown root.staff /usr/etc/in.telnetd
	# chmod 755 /usr/etc/in.telnetd

7.	Kill any existing telnet processes that may be running.

	# ps ugax | grep in.telnetd
	# kill -9 ####
	where #### is the number of each in.telnetd process found in
	the previous command.  Please note that this command may
	disrupt ongoing sessions of users attempting to use the
	system.  As an alternative to this step, you may consider
	rebooting the computer, allowing time for all current users to
	log out.

Once you have verified that the new version of telnet is operational,
it is advisable to delete the unpatched version of the utility
(/usr/etc/in.telnetd.FCS) to prevent its unauthorized use.

For additional information or assistance, please contact CIAC:   
 
	Tom Longstaff
	(415) 423-4416 or (FTS) 543-4416

	Call CIAC at (415) 422-8193 or (FTS) 532-8193 or 
        send e-mail to ciac@cheetah.llnl.gov.  
    
	Send FAX messages to:  (415) 423-0913 or (FTS) 543-0913

Sun Microsystems provided information contained 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.
Organization:  National Institute of Standards and Technology (NIST)
Sub-Organization:  National Computer Systems Laboratory



***********************************************************************
DDN Security Bulletin 9104       DCA DDN Defense Communications System
5 APR 91                Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.67.67.20]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9001).
**********************************************************************

                   Unauthorized Password Change Requests
                            Via Mail Messages


+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

CA-91:03                       CERT Advisory
                               April 4, 1991
                    Unauthorized Password Change Requests
                             Via Mail Messages

---------------------------------------------------------------------------

DESCRIPTION:

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received a number of incident reports concerning the receipt of mail
instructing the user to immediately change his/her password.  The user
is further instructed to change the password to one that is specified in
the mail message. 

These mail messages can be made to look as if they have been sent from
a site administrator or root.  In reality, they may have been sent by 
an individual at a remote site, who is trying to gain access to the 
local machine via the user's account.

Several variations of these mail messages are circulating via the Internet 
community.  We are including one such example at the end of this
advisory.


IMPACT:

An intruder can gain access to a system through the unauthorized
use of the (possibly privileged) accounts whose passwords have been 
changed.


SOLUTION:

The CERT/CC recommends the following actions:

    1)  Any user receiving such a message should verify its authenticity
        with his/her system administrator before acting on the instructions
        within the mail message.  If a user has changed his/her password
        per the instructions, he/she should immediately change it again 
        to a secure password and alert his/her system administrator.

    2)  System administrators should check with their user communities
        to ensure that no user has changed his/her password in response to
        one of these mail messages.  If this has occurred, immediately
        have the password changed again.  Further, the system should be
        carefully examined for damage, or changes that may have been
        caused by the intruder.  We also ask that you please contact the
	CERT/CC.

    3)  The CERT/CC recommends that system administrators NEVER mail
        such a request to a user.  That is, NEVER send a request for
        a password change to a user and also specify the new password
        that should be used. 


---------------------------------------------------------------------------
SAMPLE MAIL MESSAGE as received by the CERT (including spelling errors, etc.)

    :

  {mail header which may or may not be local} 

    :

This is the system administration:

     Because of security faults, we request that you change your password
     to "systest001". This change is MANDATORY and should be done IMMEDIATLY.
     You can make this change by typing "passwd" at the shell prompt. Then,
     follow the directions from there on.

     Again, this change should be done IMMEDIATLY. We will inform you when
     to change your password back to normal, which should not be longer than
     ten minutes.

                Thank you for your cooperation,

                 The system administration (root)


END OF SAMPLE MAIL MESSAGE
---------------------------------------------------------------------------


If you believe that your system has been compromised, contact CERT/CC via
telephone or e-mail.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:
           CERT/CC personnel answer 7:30a.m.-6:00p.m. EST,
           on call for emergencies during other hours.

Past advisories and other computer security related information are available
for anonymous ftp from the cert.sei.cmu.edu (128.237.253.5) system.

***********************************************************************
DDN Security Bulletin 9105       DCA DDN Defense Communications System
22 APR 91               Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.67.67.20]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9001).
**********************************************************************

             ALERT REGARDING MASQUERADING ACTIVITIES

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

SCC NOTE:  The practice referred to in the following advisory as
"Social Engineering" is perhaps better known as "Masquerading."


CA-91:04                       CERT Advisory
                               April 18, 1991
			     Social Engineering
---------------------------------------------------------------------------

DESCRIPTION:

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received several incident reports concerning users receiving requests
to take an action that results in the capturing of their password.  The
request could come in the form of an e-mail message, a broadcast, or a
telephone call.  The latest ploy instructs the user to run a "test"
program, previously installed by the intruder, which will prompt the
user for his or her password.  When the user executes the program, the
user's name and password are e-mailed to a remote site.  We are
including an example message at the end of this advisory.

These messages can appear to be from a site administrator or root.  In
reality, they may have been sent by an individual at a remote site, who
is trying to gain access or additional access to the local machine via
the user's account.

While this advisory may seem very trivial to some experienced users,
the fact remains that MANY users have fallen for these tricks (refer to
CERT Advisory CA-91:03).

IMPACT:

An intruder can gain access to a system through the unauthorized use of
the (possibly privileged) accounts whose passwords have been
compromised.  This problem could affect all systems, not just UNIX 
systems or systems on the Internet.

SOLUTION:

The CERT/CC recommends the following actions:

    1)  Any users receiving such a request should verify its authenticity
        with their system administrator before acting on the instructions
        within the message.  If a user has received this type of
        request and actually entered a password, he/she should immediately
        change his/her password to a new one and alert the system 
        administrator.

    2)  System administrators should check with their user communities
        to ensure that no user has followed the instructions in such
        a message. Further, the system should be carefully examined for
	damage or changes that the intruder may have caused.  We also
	ask that you contact the CERT/CC.

    3)  The CERT/CC urges system administrators to educate their users
	so that they will not fall prey to such tricks.

---------------------------------------------------------------------------
SAMPLE MESSAGE as received by the CERT (including spelling errors, etc.)

       OmniCore is experimenting in online - high resolution graphics
       display on the UNIX BSD 4.3 system and it's derivitaves. But, we
       need you're help in testing our new product - TurboTetris.
       So, if you are not to busy, please try out the ttetris game in your
       machine's /tmp directory. just type:

       /tmp/ttetris

       Because of the graphics handling and screen-reinitialazation, you will
       be prompted to log on again. Please do so, and use your real password.
       Thanks you for your support. You'll be hearing from us soon!


                 OmniCore

END OF SAMPLE MESSAGE
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC via
telephone or e-mail.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:
           CERT/CC personnel answer 7:30a.m.-6:00p.m. EST,
           on call for emergencies during other hours.

Past advisories and other computer security related information are available
for anonymous ftp from the cert.sei.cmu.edu (128.237.253.5) system.


***********************************************************************
DDN Security Bulletin 9107      DCA DDN Defense Communications System
20 MAY 91               Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.67.67.20]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9001).
**********************************************************************

            NeXT rexd, /private/etc, Username me Vulnerabilities

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +


CA-91:06                        CERT Advisory
                                 May 14, 1991
            NeXT rexd, /private/etc, Username me Vulnerabilities

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) and
NeXT Computer, Inc. have received information concerning three
vulnerabilities in NeXT computers running various releases (see below)
of NeXTstep software.  For more information, please contact your
authorized support center.  If you are an authorized support provider,
please contact NeXT through your normal channels.

---------------------------------------------------------------------------


Problem 1 DESCRIPTION:  By default, rexd(8C) is enabled in NeXTstep
versions 2.0 and 2.1.  (Note that no NeXT software uses rexd.)

Problem 1 IMPACT:  Leaving rexd enabled allows remote users to execute
processes on a NeXT computer.

Problem 1 SOLUTION:  Comment out or remove the rexd line in
/etc/inetd.conf (unless you're using the remote execution facility),
and either restart the computer or cause inetd to re-read it's
configuration file, using:

        kill -HUP <inetd pid>



Problem 2 DESCRIPTION:  The /private/etc directory is shipped with
group write permission enabled in all NeXTstep versions through and
including 2.1.

Problem 2 IMPACT:  Group write permission in /private/etc enables any
user in the "wheel" group to modify files in the /private/etc
directory.

Problem 2 SOLUTION:  Turn off group write permission for the
/private/etc directory, using the command:

        chmod g-w /private/etc

or the equivalent operations from the Workspace Manager's Inspector
panel.



Problem 3 DESCRIPTION: Username "me" is a member of the "wheel" group
in all NeXTstep versions through and including 2.1.

Problem 3 IMPACT:  Having username "me" in the "wheel" group enables
"me" to use the su(8) command to become root (the user must still know
the root password, however).

Problem 3 SOLUTION:  Unless you have specific reason(s) not to, remove
the user "me" from the wheel group.


---------------------------------------------------------------------------

The CERT/CC would like to thank NeXT Computer, Inc. for their response
to this vulnerability.  CERT/CC would also like to thank Fuat Baran
for his technical assistance.

---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC
via telephone or e-mail.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:
           CERT/CC personnel answer 7:30a.m.-6:00p.m. EST,
           on call for emergencies during other hours.

Past advisories and other computer security related information are
available for anonymous ftp from the cert.sei.cmu.edu (128.237.253.5)
system.
***********************************************************************
DDN Security Bulletin 9108       DCA DDN Defense Communications System
23 MAY 91               Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.67.67.20]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9001).
**********************************************************************

               AT&T System V Release 4 /bin/login Vulnerability

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +



CA-91:08                        CERT Advisory
                                 May 23, 1991
               AT&T System V Release 4 /bin/login Vulnerability

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning a security vulnerability in AT&T's UNIX(r)
System V Release 4 operating system.  AT&T is providing a software upgrade 
for Release 4 operating system vendors and a patch for AT&T Computer Systems
customers.  AT&T has also provided a suggested fix for all Release 4
based systems.
  
---------------------------------------------------------------------------
I.   DESCRIPTION:

     A security vulnerability exists in /bin/login in AT&T's System V
     Release 4 operating system.


II.  IMPACT:

     System users can gain unauthorized privileges.


III. SOLUTION:
    
     A.  AT&T Computer Systems customers

         Log into the root account.  Change the execution permission on
         the file /bin/login.

         	chmod 500 /bin/login

         Contact AT&T Computer Systems at 800-922-0354 to obtain a fix.
         The numbers associated with the fix are 156 (3.5" media) and
         157 (5.25" media).

         International customers should contact their local AT&T 
         Computer Systems representative.

     B.  All other System V Release 4 based systems

         Log into the root account.  Change the execution permission on
         the file /bin/login.

                chmod 500 /bin/login

         Release 4 customers should contact their operating system
         supplier for details on the availability of the software
         update.

---------------------------------------------------------------------------
The CERT/CC would like to thank AT&T for their timely response to our
report of this vulnerability.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC via
telephone or e-mail.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:
           CERT/CC personnel answer 7:30a.m.-6:00p.m. EST,
           on call for emergencies during other hours.

Past advisories and other computer security related information are available
for anonymous ftp from the cert.sei.cmu.edu (128.237.253.5) system.
 
***********************************************************************
DDN Security Bulletin 9110       DCA DDN Defense Communications System
23 July 91              Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.67.67.20]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9001).
**********************************************************************

                     Patch for SunOS /usr/lib/lpd

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +


CA-91:10                        CERT Advisory
                                July 15, 1991
                        Patch for SunOS /usr/lib/lpd

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning the availability of a security patch 
for /usr/lib/lpd in Sun Microsystems, Inc. operating systems.  This 
problem will be fixed in SunOS 5.0.  Patches are available for SunOS 4.0.3,
SunOS 4.1, and SunOS 4.1.1 through your local Sun answer centers worldwide 
as well as through anonymous ftp to ftp.uu.net (in ~ftp/sun-dist). 
Patch ID and file information are as follows:

Fix                     Patch ID       Filename            Checksum
/usr/lib/lpd		100305-03      100305-03.tar.Z     58052   380

Please note that Sun Microsystems sometimes updates patch files.  If
you find that the checksum is different please contact Sun Microsystems
or us for verification.
---------------------------------------------------------------------------

I.   DESCRIPTION:

     A security vulnerability exists in /usr/lib/lpd in all
     existing versions of SunOS that allows an unprivileged user
     to delete any system files.
     
II.  IMPACT:

     Any user logged into the system can delete files that they do 
     not own.

III. SOLUTION:
        
     Install the new version of lpd.  You may want to alert
     users in advance that printer service will be disrupted.
     Then, before installing the patch, drain the print queues.
     This is generally done using the lpc command.  Later,
     after the patch is installed, printer queues can be
     re-enabled.
    
     As root:

     1.  Kill the currently running lpd process.  Kill -INT
         will allow the running lpd to do necessary clean-up.

         # ps -ax | grep lpd
         # kill -INT {process id of lpd found in the above command}

     2.  Move the current version aside and change the file mode
         of the old version to prevent misuse.

         # mv /usr/lib/lpd /usr/lib/lpd.OLD
         # chmod 100 /usr/lib/lpd.OLD

     3.  Install the new version of lpd

         # cp sun{3,3x,4,4c.386i}/{4.1,4.1.1}/lpd /usr/lib/lpd
         # chown root.daemon /usr/lib/lpd
         # chmod 6711 /usr/lib/lpd

     4.  Set up devices (note: new device name /dev/lpd/printer) to
         work with new lpd.  Create a link, /dev/printer, for
         compatibility purposes.

         # rm -f /dev/printer
         # mkdir /dev/lpd
         # chown root.daemon /dev/lpd
         # chmod 710 /dev/lpd
         # ln -s /dev/lpd/printer /dev/printer

     5.  Modify line printer program protections

         # chmod 6711 /usr/ucb/lpr
         # chmod 6711 /usr/ucb/lpq
         # chmod 6711 /usr/ucb/lprm
         # chmod 2711 /usr/etc/lpc

     6.  Restart lpd

         # /usr/lib/lpd

     7.  Edit /etc/rc or /etc/rc.local file and change the line that removes
         the /dev/printer file upon system startup. It should reflect
         the change in location from /dev/printer to /dev/lpd/printer.

         Original:

         if [ -f /usr/lib/lpd ]; then
                 rm -f /dev/printer /var/spool/lpd.lock

         Change to:

         if [ -f /usr/lib/lpd ]; then
                 rm -f /dev/lpd/printer /var/spool/lpd.lock
                           ^^^^
                           NEW

         The results should look like:
         if [ -f /usr/lib/lpd ]; then
                 rm -f /dev/lpd/printer /var/spool/lpd.lock
                 /usr/lib/lpd;           echo -n ' printer'
         fi


---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC via
telephone or e-mail.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:
           CERT/CC personnel answer 7:30a.m.-6:00p.m. EST,
           on call for emergencies during other hours.

Past advisories and other computer security related information are available
for anonymous ftp from the cert.sei.cmu.edu (192.88.209.5) system.
***********************************************************************
DDN Security Bulletin 9112       DCA DDN Defense Communications System
23 August 91            Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.67.67.20]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9001).
**********************************************************************

                    Trusted Hosts Configuration Vulnerability

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

CA-91:12                        CERT Advisory
                               August 22, 1991
                    Trusted Hosts Configuration Vulnerability

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning a vulnerability in the configuration
of several system files.  This advisory discusses a workaround since
there are no permanent patches available at this time.

This vulnerability is present in a very large number of UNIX-based
operating systems. Therefore, we recommend that ALL sites take the 
corrective actions listed below.

---------------------------------------------------------------------------

I.   DESCRIPTION:

     The presence of a '-' as the first character in /etc/hosts.equiv,
     /etc/hosts.lpd and .rhosts files may allow unauthorized access 
     to the system.
     
II.  IMPACT:

     Remote users can gain unauthorized root access to the system.

III. SOLUTION:
        
     Rearrange the order of entries in the hosts.equiv, hosts.lpd,
     and .rhosts files so that the first line does not contain 
     a leading '-' character.

     Remove hosts.equiv, hosts.lpd, and .rhosts files containing only 
     entries beginning with a '-' character.

     .rhosts files in ALL accounts, including root, bin, sys, news, etc.,
     should be examined and modified as required.  .rhosts files that
     are not needed should be removed.    

     Please note that the CERT/CC strongly cautions sites about the
     use of hosts.equiv and .rhosts files.  We suggest that they NOT
     be used unless absolutely necessary.  

---------------------------------------------------------------------------
The CERT/CC wishes to thank Alan Marcum, NeXT Computer, for bringing
this security vulnerability to our attention.  We would also like to
thank CIAC for their assistance in testing this vulnerability.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC via
telephone or e-mail.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:
           CERT/CC personnel answer 7:30a.m.-6:00p.m. EST,
           on call for emergencies during other hours.

Past advisories and other computer security related information are available
for anonymous ftp from the cert.sei.cmu.edu (192.88.209.5) system.
***********************************************************************
DDN Security Bulletin 9113       DCA DDN Defense Communications System
23 August 91            Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.67.67.20]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9001).
***********************************************************************

                    DEC ULTRIX /usr/bin/mail Vulnerability

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

CA-91:13                        CERT Advisory
	  		       August 23, 1991
                    DEC ULTRIX /usr/bin/mail Vulnerability
-------------------------------------------------------------------------------
 
The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning a vulnerability in all versions of Digital
Equipment Corporation's (DEC) ULTRIX operating system prior to 4.2 and
applicable to all Digital Equipment Corporation architectures.
The vulnerability has been fixed in ULTRIX version 4.2.

This vulnerability allows any user logged into the system to obtain a root
shell. 

Appended is an update to a Digital Equipment Corporation DSNlink/ DSIN FLASH
which describes the vulnerability and Digital Equipment Corporation's
recommended solution.
 
If you have any inquiries regarding Digital Equipment Corporation's document,
please contact your Digital Services Support Organization.

===============================================================================
Start of Digital Equipment Corporation's Document.

-------------------------------------------------------------------------------
SOURCE: Digital Equipment Corporation.

COPYRIGHT (c) 1988, 1989, 1990 by Digital Equipment Corporation.
ALL RIGHTS RESERVED.
 
 
INFORMATION:
 
ULTRIX V4.1 - Security Vulnerability Identified in /usr/bin/mail
 
 
PROBLEM:
 
A potential security vulnerability has been identified in ULTRIX 
Version  4.1 where, under certain circumstances, user privileges 
can be expanded via /usr/bin/mail.  This problem applies to both  
the VAX and DEC RISC (i.e. DECsystem  and DECstation ) architectures.  
 
As always, Digital urges you to regularly review your system 
management and security procedures.  Digital will continue to review 
and enhance security features, and work with our customers to further
improve the integrity of their systems. 
 
 
SOLUTION:
 
Digital has corrected the identified code as of ULTRIX Version 4.2
(released  May 1991).  Digital recommends strongly that you upgrade to 
ULTRIX Version 4.2 immediately to avoid any potential vulnerability  
to your system via this problem.  For those of you who are unable to 
upgrade at this time, installing the ULTRIX Version 4.2 mail file on 
your V4.1 system will correct this problem.
 
ULTRIX Version 4.2 of /usr/bin/mail has not been shown to be 
compatible with versions of ULTRIX previous to ULTRIX version 4.1; 
upgrading to ULTRIX V4.2 or upgrading to ULTRIX V4.1 and using the 
ULTRIX 4.2 /usr/bin/mail program is required to correct this  
problem.
 
Use one of the procedures below to update an ULTRIX Version 4.1 system:
 
         - Procedure   (1)   describes the process to extract the 
           /usr/bin/mail binary from the ULTRIX Version 4.2 MUP subset. 
 
         - Procedure   (2)   provides the commands to install the 
           ULTRIX Version 4.2 /usr/bin/mail binary from another of your 
           system(s) where possible.
 
         - Both  the  VAX  (DECsystem)  and DEC RISC (DECstation) 
           versions of the ULTRIX Version 4.2 /usr/bin/mail binary, 
	   may be obtained by contacting your Digital Services Support 
           Organization.
 
 
-------------------------------------------------------------------------------
 
(1)     This procedure will replace your existing /usr/bin/mail binary using 
        the /usr/bin/mail binary from the ULTRIX Version 4.2 MUP distribution.
        The procedure below describes the method to extract the binary from
        the tape media.
 
NOTE: 
 
Setting the environment to single user mode will prevent possible
disruption of the mail services.
-------------------------------------------------------------------------------
 
        To update an ULTRIX Version 4.1 system, you must first obtain the 
        ULTRIX Version 4.2 binary  of  /usr/bin/mail for your computer's  
        architecture from your ULTRIX Version 4.2 distribution tapes.
 
  LOAD THE ULTRIX MANDATORY UPGRADE TAPE ON YOUR ULTRIX Version 4.1 SYSTEM.
 
        ( Note: UDTBASE421 will provide the RISC base upgrade, ULTBASE421 will)
        ( provide the VAX base upgrade mail file.  Substitute as necessary for)
        ( your architecture. )
 
  ( ISSUE THE FOLLOWING COMMANDS FROM YOUR ULTRIX Version 4.1 SYSTEM )

  ( BECOME ROOT - YOU MUST HAVE PRIVILEGES TO MAKE THIS UPDATE. )
  
   % su 
 
  (cd TO SOME DIRECTORY THAT YOU CAN PUT THE FILE IN TEMPORARILY, e.g. cd /tmp)
 
   # cd /tmp 
 
  (NOTE: YOU WILL NEED APPROXIMATELY 2 MB of DISK SPACE )
 
   # mkdir ./usr
   # mkdir ./usr/etc
   # mkdir ./usr/etc/subsets
   # setld -x /dev/nrmt0h {UDTBASE421 or ULTBASE421}
 
 
  ( LIST THE SUBSET, CREATE THE FILE UDTBASE421 or ULTBASE0421, THEN EXTRACT )
  ( THE MAIL FILE /usr/bin/mail {NOTE} THIS EXAMPLE USES THE "RISC" SUBSET   ) 
 
 
   # ls
   # mv UDTBASE421 UDTBASE421.Z
   # zcat UDTBASE421.Z | tar xvf - ./usr/bin/mail
 
  ( MOVE THE ULTRIX V4.2 BINARY TO /usr/bin/mail CHANGE PROTECTION, OWNER etc.)
 
   # cd /usr/bin
   # mv mail mail.old
   # chmod 600 mail.old
   # mv /tmp/usr/bin/mail .
   # chown root mail
   # chgrp kmem mail
   # chmod 6755 mail
        
-------------------------------------------------------------------------------
(2)    To update the /usr/bin/mail binary from an existing V4.2 
       (similar platform (VAX or RISC)) remote node, copy the 
       file to your system and store it in a temporary location 
       (e.g., - /tmp/mail).
       The procedure below provides an example using DECnet.  Use the 
       copy command that fits your environment to copy the /usr/bin/mail
       binary from a remote node to the /tmp directory on your local
       system.
 
NOTE: 
 
Setting the environment to single user mode will prevent possible
disruption of the mail services.
-------------------------------------------------------------------------------
 
 % dcp -iv {remote-nodename}/{username}/{password}::'/usr/bin/mail' '/tmp/mail'
 
  ( ISSUE THE FOLLOWING COMMANDS FROM YOUR ULTRIX Version 4.1 SYSTEM )

  ( BECOME ROOT - YOU MUST HAVE PRIVILEGES TO MAKE THIS UPDATE. )
  
   % su 
   # cd /usr/bin
   # mv mail mail.old
   # chmod 600  mail.old
 
  ( MOVE THE ULTRIX V4.2 BINARY TO /usr/bin/mail CHANGE PROTECTION, OWNER etc.)
                               
   # mv /tmp/mail /usr/bin/mail
   # chown root mail
   # chgrp kmem mail
   # chmod 6755 mail
 
-------------------------------------------------------------------------------
End of Digital Equipment Corporation Document.
===============================================================================

-------------------------------------------------------------------------------
The CERT/CC would like to thank Tsutomu Shimomura for his assistance and
Digital Equipment Corporation for their response to this vulnerability.
-------------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC via
telephone or e-mail.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:
           CERT/CC personnel answer 7:30a.m.-6:00p.m. EST,
           on call for emergencies during other hours.

Past advisories and other computer security related information are
available for anonymous ftp from the cert.sei.cmu.edu (192.88.209.5)
system.
***********************************************************************
DDN Security Bulletin 9114       DCA DDN Defense Communications System
27 Aug 91               Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.67.67.20]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9001).
**********************************************************************

                     SGI "IRIX" /usr/sbin/fmt Vulnerability

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +



CA-91:14                        CERT Advisory
                               August 26, 1991
                     SGI "IRIX" /usr/sbin/fmt Vulnerability

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning a vulnerability of mail messages in Silicon
Graphics Computer Systems' IRIX versions prior to 4.0 (this includes all
3.2 and 3.3.* versions).  This problem has been fixed in version 4.0.

Information regarding the exploitation of this vulnerability is inherently 
disclosed by any discussion of the problem (including this Advisory) so 
we recommend taking immediate action. Until you are able to apply the patch, 
mail at your site is vulnerable to being read by any ordinary user logged 
in at that site.

Silicon Graphics has provided the enclosed patch instructions.

---------------------------------------------------------------------------

I.   DESCRIPTION:

     A vulnerability exists such that IRIX pre-4.0 (e.g., 3.3.3) systems
     with the basic system software ("eoe1.sw.unix") installed can allow
     unauthorized read access to users' mail messages, by exploiting a
     configuration error in a standard system utility. Due to the ease
     of exploiting this vulnerability and the simplicity of the corrective
     action, the CERT/CC urges all sites to install the patch given below.

II.  IMPACT:

     Anyone who can log in on a given IRIX pre-4.0 (3.2, 3.3, 3.3.*) system
     can read mail messages which have been delivered to any other user on
     that same system.

III. SOLUTION:
        
     As "root", execute the following commands:

	chmod 755 /usr/sbin/fmt
	chown root.sys /usr/sbin/fmt

     If system software should ever be reloaded from a 3.2 or 3.3.*
     installation tape or from a backup tape created before the patch
     was applied, repeat the above procedure immediately after the software
     has been reloaded, before enabling logins by normal users.

     [Fixed in IRIX 4.0.]


---------------------------------------------------------------------------
The CERT/CC would like to thank Silicon Graphics for bringing this
vulnerability and solution to our attention.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC via
telephone or e-mail.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:
           CERT/CC personnel answer 7:30a.m.-6:00p.m. EST,
           on call for emergencies during other hours.

Past advisories and other computer security related information are available
for anonymous ftp from the cert.sei.cmu.edu (192.88.209.5) system.

***********************************************************************
DDN Security Bulletin 9116       DCA DDN Defense Communications System
16 Sep 91               Published by: DDN Security Coordination Center
Supersedes DDN Sec. Bull. 9110       (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.67.67.20]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9001).
**********************************************************************

                  New Patch for SunOS /usr/lib/lpd

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +



CA-91:10a                       CERT Advisory
                              September 12, 1991
               REVISION NOTICE: New Patch for SunOS /usr/lib/lpd

---------------------------------------------------------------------------

                 *** THIS IS A REVISED CERT ADVISORY ***
                    *** CONTAINS NEW INFORMATION ***

There were a number of problems with various early versions of Sun
Microsystems, Inc. (Sun) /usr/lib/lpd patch ( Patch ID 100305-xx ).  
While security problems were fixed in the patches, a remote print
spooling problem was introduced.  Sun believes all the problems have 
been fixed and they are now releasing the enclosed information 
concerning a new patch version.  They have given the CERT/CC permission 
to distribute this information.

The Computer Emergency Response Team/Coordination Center (CERT/CC) 
recommends that all affected sites follow the information provided 
by Sun Microsystems in this bulletin.

---------------------------------------------------------------------------
START OF SUN-SUPPLIED INFORMATION
===========================================================================


SUN MICROSYSTEMS SECURITY BULLETIN:

This information is only to be used for the purpose of alerting
customers to problems. Any other use or re-broadcast of this 
information without the express written consent of Sun Microsystems
shall be prohibited.


Sun expressly disclaims all liability for any misuse of this information
by any third party.
---------------------------------------------------------------------------


This is more an update on the lpd fix than any new information.

First the update.

After a lengthy beta test cycle, there is now available a new version
of the lpd security fix.  The patch-ID# is 100305-06.

This patch is available via anonymous ftp from the ftp.uu.net system in the
sun-dist directory as 100305-06.tar.Z, or through your local Sun Answer 
Center.  The checksum information for the file available from ftp.uu.net is:

                24474   440   100305-06.tar.Z

--------------------------------------------------------------------------

Some history.

An lpd bug was discovered where lpd could be used to remove system files
(/etc/passwd or /.rhosts as examples). This bug was fixed with 100305-01.

A second bug was also shown that could still be used to remove system files.
This fix was rolled into 100305-02.

An lpc problem that touched one of the same modules as in the lpd fix was fixed
and the subsequent change rolled into the lpd patch 100305-03.

Two additional problems were sent to Sun: one having to do with RPC calls to
lpd and the second having to do with postscript calls to lpd, thus 100305-04.

It was in creating the -04 version that we unknowingly introduced a remote
spool problem on the SunOS 4.1.1 version of the patch. The problem was that
if the remote queue had jobs in it, the local job sent was often truncated
to zero length.

The -05 version was an attempt to back out the last few changes to remove the
remote print problem.  Unfortunately, it did not.  It was at this time that
we decided to do a lengthy evaluation and test cycle to ensure that the newest
version fixed all the reported problems as well as fixed the remote
spool bug we had introduced.

The 100305-06 patch is the result of that lengthy test cycle.

Thank you all for your support through all this.

Brad Powell
Software Security Coordinator
Sun Microsystems.

===========================================================================
END OF SUN-SUPPLIED INFORMATION
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC via
telephone or e-mail.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:
           CERT/CC personnel answer 7:30a.m.-6:00p.m. EST,
           on call for emergencies during other hours.

Past advisories and other computer security related information are available
for anonymous ftp from the cert.sei.cmu.edu (192.88.209.5) system.


***********************************************************************
DDN Security Bulletin 9117       DCA DDN Defense Communications System
18 Sep 91               Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.67.67.20]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9001).
**********************************************************************

                  SunOS SPARC Integer Division Vulnerability

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +



CA-91:16                        CERT Advisory
                              September 18, 1991
                    SunOS SPARC Integer Division Vulnerability

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning a vulnerability in Sun Microsystems,
Inc. (Sun) integer division on their SPARC architecture.  This vulner-
ability exists on all SPARC platforms (including sun4 and sun4c)
for SunOS versions 4.1 and 4.1.1.

Sun has provided patches for this vulnerability. They are available through
your local Sun Answer Centers worldwide as well as through anonymous
ftp from the ftp.uu.net system (in the sun-dist directory).  

Fix                        Patch ID       Filename            Checksum
/sys/sun{4,4c}/OBJ/crt.o   100376-01      100376-01.tar.Z     09989    11

Please note that Sun Microsystems sometimes updates patch files.  If
you find that the checksum is different please contact Sun Microsystems
or us for verification.
---------------------------------------------------------------------------

I.   Description

     A security vulnerability exists in the integer division
     on the SPARC architecture that can be used to gain root
     privileges.
     
II.  Impact

     Any user logged into the system can gain root access.

III. Solution 
        
     Replace /sys/sun{4,4c}/OBJ/crt.o and rebuild the kernel(s)
     necessary for your host configuration(s).  Reboot each host
     using the appropriate kernel.

     Please refer to the System and Network Administration
     Manual for instructions on building and configuring a
     new custom kernel.

---------------------------------------------------------------------------
The CERT/CC wishes to thank Gordon Irlam of the Department of Computer,
University of Adelaide, Australia, for bringing this vulnerability to
our attention and for his further assistance with the solution.  We
also wish to thank Sun Microsystems for their prompt response to this 
vulnerability.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC via
telephone or e-mail.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:
           CERT/CC personnel answer 7:30a.m.-6:00p.m. EDT,
           on call for emergencies during other hours.

Past advisories and other computer security related information are available
for anonymous ftp from the cert.sei.cmu.edu (192.88.209.5) system.

 
**************************************************************************
Security Bulletin 9118              DISA Defense Communications System
1 October 1991          Published by: DDN Security Coordination Center
                                  (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN is distributed  by the  DDN SCC  (Security
Coordination Center) under DISA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.112.36.5]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9118).
**************************************************************************

	Vulnerability of DECnet-Internet gateway software
	in (DEC) ULTRIX versions 4.0, 4.1, and 4.2.


+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Communications Agency's Security Coordination     !
!     Center  distribution  system  as a  means  of  providing  DDN     !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

CA-91:17                        CERT Advisory
                              September 26, 1991
                      DECnet-Internet Gateway Vulnerability

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning a vulnerability in the configuration of
the DECnet-Internet gateway software for Digital Equipment Corporation's 
(DEC) ULTRIX versions 4.0, 4.1, and 4.2 on all Digital architectures.

Digital Equipment Corporation is aware of this problem and a resolution
for this vulnerability will be included in a future release.  Digital
and the CERT/CC strongly recommend that sites exposed to this vulnerability 
immediately institute the workaround detailed in this advisory.

---------------------------------------------------------------------------

I.   Description

     When installing the DECnet-Internet gateway software it is necessary to
     create a guest account on the ULTRIX gateway host.  By default, this
     account has /bin/csh as its shell.  By virtue of the guest account
     having a valid shell, the DECnet-Internet gateway software can be
     exploited to allow unauthorized root access.

II.  Impact

     Anyone using the DECnet-Internet gateway can gain unauthorized
     root privileges on the ULTRIX gateway host.

III. Solution
        
     This section describes a workaround for this vulnerability.

     Disable the guest account by editing the /etc/passwd file and setting
     the shell field for the guest account to /bin/false.  Also, ensure the 
     guest account has the string "NoLogin" in the password field as detailed
     in the DECnet-Internet installation manual.  

     Even if you have not installed or are not running the DECnet-
     Internet gateway software, Digital recommends that you implement the
     workaround solution stated above.

---------------------------------------------------------------------------
The CERT/CC wishes to thank R. Scott Butler of the Du Pont Company for 
bringing this vulnerability to our attention and for his further 
assistance with the temporary workaround.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC via
telephone or e-mail.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:
           CERT/CC personnel answer 7:30a.m.-6:00p.m. EST/EDT,
           on call for emergencies during other hours.

Past advisories and other computer security related information are available
for anonymous ftp from the cert.sei.cmu.edu (192.88.209.5) system.
**************************************************************************
Security Bulletin 9120              DISA Defense Communications System
21 October 1991         Published by: DDN Security Coordination Center
                                  (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
Coordination Center) under DISA contract as a means of communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.112.36.5]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9120).
**************************************************************************

			RE-REGISTRATION OF TAC USERS

	THIS BULLETIN IS MEANT TO NOTIFY ALL CONCERNED THAT THERE
	IS CURRENTLY A PROBLEM WITH THE TIMELINESS OF TAC USERS
	BEING RE-REGISTERED WITH THE NETWORK INFORMATION CENTER (NIC)
	ONCE THEIR HOSTS ARE MOVED BEHIND CONCENTRATORS/GATEWAYS.
	SPECIFICALLY, WHEN A MILNET DIRECT-CONNECTED HOST IS
	DISCONNECTED AMD MOVED BEHIND A CONCENTRATOR/GATEWAY HOST,
	USERS BEHIND THE ORIGINAL "AUTHORIZING" HOST NEED TO BE RE-
	REGISTERED WITH THE CONCENTRATOR/GATEWAY AS THE AUTHORIZING
	"HOST."  THIS IS NOT HAPPENING IN ALL CASES, OFTEN DUE TO
	HOST ADMINISTRATORS ASSUMING THEY WILL CONTINUE TO BE ABLE TO
	AUTHORIZE TAC CARDS AFTER THEIR HOST IS RE-CONNECTED, AND TO
	CONCENTRATOR/GATEWAY ADMINISTRATORS ASSUMING THAT THEY DO NOT
	PLAY A ROLE IN THE TAC CARD AUTHORIZATION PROCESS.
 
	BEGINNING 15 DECEMBER 1991, THE NIC HAS BEEN DIRECTED TO
	TERMINATE NETWORK ACCESS TO ALL TAC USERS UTILIZING TAC CARDS
	REGISTERED TO "OLD" DIRECT CONNECTED HOSTS.  THE USE OF THESE
	CARDS IS NO LONGER AUTHORIZED UNLESS RE-REGISTRATION HAS BEEN
	ACCOMPLISHED AS DESCRIBED ABOVE.  IN THE FUTURE, TAC ACCESS
	WILL BE TERMINATED WITHIN 15 DAYS AFTER ANY HOST HAS BEEN
	DECONFIGURED.  IT IS, THEREFORE, INCUMBENT UPON HOST
	ADMINISTRATORS TO COORDINATE WITH THE ADMINISTRATOR OF THE
	CONCENTRATOR/GATEWAY AND WITH THE NIC REGISTRAR TO ARRANGE THE
	TIMELY RE-REGISTRATION OF TAC USERS PRIOR TO THE DISCONNECTION
	OF THE HOST TO WHICH THOSE TAC USERS WERE ORIGINALLY REGISTERED.
 
	FOR FURTHER INFORMATION REGARDING THIS GENERAL POLICY OR TO
	COORDINATE SPECIFIC CASES, PLEASE SEND A MESSAGE TO
	REGISTRAR@NIC.DDN.MIL OR CALL 1-800-365-3642/703-802-4535.

**************************************************************************
Security Bulletin 9121              DISA Defense Communications System
21 October 1991         Published by: DDN Security Coordination Center
                                  (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN is distributed  by the  DDN SCC  (Security
Coordination Center) under DISA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.112.36.5]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9121).
**************************************************************************
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center  distribution  system  as a  means  of        !
!     providing  DDN subscribers with useful security information.      !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
===========================================================================
CA-91:19                        CERT Advisory
                              October 17, 1991
                        AIX TFTP Daemon Vulnerability

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning a vulnerability in the TFTP daemon in
all versions of AIX for IBM RS/6000 machines.

IBM is aware of this problem and a fix is available as apar number "ix22628".
This patch is available for all AIX releases from "GOLD" to the current
release.

NOTE: THIS IS AN UPDATED PATCH FROM ONE RECENTLY MADE AVAILABLE and fixes
a security hole in the original patch.  The SCCS id of the correct patch
is tftpd.c 1.13.1.3 (*not* 1.13.1.2 or earlier versions).  This can be 
checked using the following "what" command.

    % what /etc/tftpd
    /etc/tftpd:
       56      1.13.1.3  tftpd.c, tcpip, tcpip312 10/10/91 09:01:48
       tftpsubs.c      1.2  com/sockcmd/tftpd,3.1.2,9048312 10/8/89 17:40:55

IBM customers may call IBM Support (800-237-5511) and ask that the fix
be shipped to them.  The fix will appear in the upcoming 2009 update
and the next release of AIX.

---------------------------------------------------------------------------

I.   Description

     Previous versions of tftpd did not provide a method for restricting 
     TFTP access.

II.  Impact

     If TFTP is enabled at your site, anyone on the Internet can retrieve
     copies of your site's world-readable files, such as /etc/passwd.

III. Solution
        
     A. Sites that do not need to allow tftp access should disable it.
	This can be done by editing /etc/inetd.conf and deleting or
	commenting out the tftpd line:

	#tftp     dgram     udp    wait    nobody  /etc/tftpd     tftpd -n

	and then, as root, restarting inetd with the "refresh" command.

	    # refresh -s inetd

	For more details on starting/stopping tftp, refer to documentation
	for the System Resource Controller (SRC) or the System Management
	Interface Tool (SMIT).

     B. Sites that must run tftpd (for example, to support X terminals)
	should obtain and install the above patch AND create a
	/etc/tftpaccess.ctl file to restrict the files that are accessible.
        The /etc/tftpaccess.ctl file should be writable only by root.
	Although the new /etc/tftpaccess.ctl mechanism provides a very general
	capability, the CERT/CC strongly recommends that sites keep this
	control file simple.  For example, the following tftpaccess.ctl file
	is all that is necessary to support IBM X terminals:

	# /etc/tftpaccess.ctl
	# By default, all files are restricted if /etc/tftpaccess.ctl exists.
	# Allow access to X terminal files.
	allow:/usr/lpp/x_st_mgr/bin

	NOTE: Be CERTAIN to create the /etc/tftpaccess.ctl file.
	If it does not exist then all world-readable files are accessible
	as in the current version of tftpd.

        Installation Instructions:

        1.  Create an appropriate /etc/tftpaccess.ctl file.

        2.  From the directory containing the new tftpd module, issue
            the following commands as root.
        
            # chmod 644 /etc/tftpaccess.ctl
            # chown root.system /etc/tftpaccess.ctl
	    # mv /etc/tftpd /etc/tftpd.old
	    # cp tftpd /etc
	    # chmod 755 /etc/tftpd
	    # chown root.system /etc/tftpd
	    # refresh -s inetd

---------------------------------------------------------------------------
The CERT/CC wishes to thank Karl Swartz of the Stanford Linear Accelerator
Center for bringing this vulnerability to our attention.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC via
telephone or e-mail.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:
           CERT/CC personnel answer 7:30a.m.-6:00p.m. EST/EDT,
           on call for emergencies during other hours.

Past advisories and other computer security related information are available
for anonymous ftp from the cert.sei.cmu.edu (192.88.209.5) system.
**************************************************************************
Security Bulletin 9122                  DISA Defense Communications System
23 October 1991             Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN is distributed  by the  DDN SCC  (Security
Coordination Center) under DISA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.112.36.5]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9122).
**************************************************************************

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center  distribution  system  as a  means  of        !
!     providing  DDN subscribers with useful security information.      !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

===========================================================================
CA-91:20                        CERT Advisory
                              October 22, 1991
                        /usr/ucb/rdist Vulnerability

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning a vulnerability in /usr/ucb/rdist (the 
location of rdist may vary depending on the operating system).  This 
vulnerability is present in possibly all versions of rdist.  Vendors 
responding with patches are listed below.  Additionally, some vendors 
who do not include rdist in their operating systems are identified.  
Operating systems from vendors not listed in either of the two categories 
below will probably be affected and the CERT/CC has proposed a workaround 
for those systems.

VENDORS THAT DO NOT SHIP 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 DG/UX for AViiON Systems

	
VENDORS PROVIDING PATCHES 

  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.x/4.0 (fixed in 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.


The CERT/CC is hopeful that other patches will be forthcoming.  We will
be maintaining a status file, rdist-patch-status, on the cert.sei.cmu.edu
system.  We will add patch availability information to this file as
it becomes known.  The file is available via anonymous ftp to
cert.sei.cmu.edu and is found in pub/cert_advisories/rdist-patch-status.

All trademarks are the property of their respective holders.
---------------------------------------------------------------------------

I.   Description

     A security vulnerability exists in /usr/ucb/rdist that
     can be used to gain unauthorized privileges.  Under some
     circumstances /usr/ucb/rdist can be used to create setuid
     root programs.

II.  Impact

     Any user logged into the system can gain root access.

III. Solution
        
     A.  If available, install the appropriate patch provided by
         your operating system vendor.

     B.  If no patch is available, restrict the use of /usr/ucb/rdist
         by changing the permissions on the file.

         # chmod 711 /usr/ucb/rdist

---------------------------------------------------------------------------
The CERT/CC wishes to thank Casper Dik of the University of Amsterdam,
The Netherlands, for bringing this vulnerability to our attention.
We would also like to thank the vendors who have responded to this problem.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC via
telephone or e-mail.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:
           CERT/CC personnel answer 7:30a.m.-6:00p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

Past advisories and other computer security related information are available
for anonymous ftp from the cert.sei.cmu.edu (192.88.209.5) system.
**************************************************************************
Security Bulletin 9124                  DISA Defense Communications System
5 December 1991             Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN is distributed  by the  DDN SCC  (Security
Coordination Center) under DISA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.112.36.5]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9124).
**************************************************************************

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important information was issued by the Computer    !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center  distribution  system  as a  means  of        !
!     providing  DDN subscribers with useful security information.      !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

-------------------------------------------------------------------------------


                    CERT/CC Generic Security Information

The following information is provided to sites that have, or may have,
experienced a break-in.  Section A lists several ways to determine if a system
has been compromised.  Sections B and C contain lists of vulnerabilities that
have been exploited by intruders on UNIX and VMS systems respectively.
Section D gives pointers to some tools that may be used to assist in securing
your system.

The information in this document can be used to prevent several types of
break-ins.  We encourage system administrators to review all sections of this
document and modify their systems accordingly to close these potential
vulnerabilities. 

-------------------------------------------------------------------------------

A.  How To Determine If Your System Has Been Compromised

    1.  Examine log files such as your 'last' log, process accounting, syslog,
        and C2 security logs for logins from unusual locations or other unusual
        activity.  Note that this is not foolproof; many intruders edit
        accounting files in an attempt to hide their activity.


    2.  Look everywhere on the system for unusual or hidden files (files that
        start with a period and are normally not shown by ls) as these can be
        used to hide information such as password cracking programs and
        password files from other systems.  A favorite trick on UNIX systems
        is to put a hidden directory in a user's account with an unusual name;
        something like '...' or '..  ' (dot dot space space) or '..^G' (dot
        dot control-G).  Also, files with names such as '.xx' and '.mail' have
        been used.


    3.  Look for set-uid files everywhere on your system.  Intruders often
        leave set-uid copies of /bin/sh around to allow them root access at a
        later time.  The UNIX find program can be used to hunt for setuid root
        files.  The following example will find setuid root files on the '/'
        (root) partition (Note:  The find command will not follow symbolic
        links):

                  find / -user root -perm -4000 -print


    4.  Check your system binaries to make sure that they haven't been changed.
        We've seen intruders change programs on UNIX systems such as login,
        su, telnet, and other critical network and system programs.  On VMS
        systems, we've seen intruders change programs such as loginout.exe and
        show.exe.  Compare the versions on your systems with known good copies
        such as those from your initial installation tapes.  Be careful of
        trusting backups; your backups could also contain Trojan horses.


    5.  Examine all the files that are run by cron and at.  We've seen
        intruders leave back doors in files run from cron or submitted to at.
        These techniques can let an intruder back on the system even after
        you've kicked him or her off.  Also, verify that all files/programs
        referenced (directly or indirectly) by the cron and at jobs, and the
        job files themselves, are not world-writable.


    6.  Inspect /etc/inetd.conf for unauthorized additions or changes.  In
        particular, hunt for entries that execute a shell program
        (for example, /bin/sh or /bin/csh) and check all programs that are
        specified in /etc/inetd.conf to verify that they are correct and
        haven't been replaced by Trojan horses.


    7.  Check your system and network configuration files for unauthorized
        entries.  In particular, look for '+' (plus sign) entries and
        inappropriate non-local host names in /etc/hosts.equiv, /etc/hosts.lpd,
        and in all ~/.rhost files (especially ~root, ~uucp, ~ftp, and other
        system accounts) on the system.  These files should not be
        world-writable.  Furthermore, ensure that these files existed prior to
        any intrusion and have not been created by the intruder.  


    8.  Examine all machines on the local network when searching for signs of
        intrusion.  In particular, check those hosts that share NIS (yellow
        pages) or NFS mounted partitions, or that are referenced in
        /etc/hosts.equiv files.  Also, check any hosts with which your users
        share .rhost access.


    9.  Examine the /etc/passwd file on the system and check for any
        additional or modified accounts.  In particular, look for the
        unauthorized creation of new accounts, accounts with no passwords, or
        UID changes to existing accounts.


B.  UNIX System Configuration Problems That Have Been Exploited

    1.  Weak passwords

        Intruders often use finger or ruser to discover account names and then
        try simple passwords.  Encourage your users to choose passwords that
        are difficult to guess (for example, words that are not contained in
        any dictionary of words of any language; no proper nouns, including
        names of "famous" real or fictitious characters; no acronyms that are
        common to computer professionals; no simple variations of first or last
        names.  Furthermore, inform your users not to leave any clear text
        username/password information in files on any system. 

        A good heuristic for choosing a password is to choose an
        easy-to-remember phrase, such as "By The Dawn's Early Light", and take
        the first letters to form a password.  Insert in some punctuation or
        mixed case letters as well.  For the phrase above, one example password
        might be: bt}DeL{.  (DO NOT use this sample phrase for your password.)

        If intruders can get a password file, they will usually take it to
        another machine and run password guessing programs on it.  These
        programs involve large dictionary searches and run quickly even on
        slow machines.  The experience of many sites is that most systems that
        do not put any controls on the types of passwords used probably have
        at least one password that can be easily guessed.

        If you believe that your password file may have been taken, change all
        the passwords on the system.  At the very least, you should always
        change all system passwords because an intruder may concentrate on
        those and may be able to guess even a reasonably 'good' password.

        Section D details proactive steps that can be taken to ensure that
        users set 'good' passwords and that encrypted passwords are not
        visible to system users.


    2.  Use of TFTP (Trivial File Transfer Protocol) to steal password 
        files 

        To test your system for this vulnerability, connect to your system
        using tftp and try 'get /etc/passwd'.  If you can do this, anyone else
        on the network can probably get your password file.  To avoid this
        problem, either disable tftpd if you don't require it or ensure that
        it is configured with restricted access. 

        If you believe your password file may have been taken, the safest
        course is to change all passwords in the system.


    3.  Accounts without passwords or known passwords (accounts
        with vendor-supplied default passwords are favorites) 

        Intruders often exploit system default passwords that have not been
        changed since installation.  Be sure to change all default passwords
        when the software is installed.  Also, be aware that product upgrades
        can quietly change account passwords to a new default.  It is best to
        change the passwords of default accounts after updates are applied.

        Scan your password file for extra UID 0 accounts, accounts with no
        password, or new entries in the password file.  Do not allow any
        accounts without passwords.  Remove entries for unused accounts from
        the password file.  To disable an account, change the password field in
        the /etc/passwd file to an asterisk '*', and change the login shell to
        /bin/false to ensure that an intruder cannot login to the account from
        a trusted system on the network.


    4.  Holes in sendmail

        Make sure that you are running the latest sendmail from your vendor.
        BSD 5.65 fixes all known holes.  To establish which version of
        sendmail that you are running, use telnet to connect to the SMTP
        port (25) on your system:

                    telnet <your hostname> 25


    5.  Old versions of FTP;  misconfigured anonymous FTP

        Make sure that you are running the most recent version of ftpd, which
        is the Berkeley version 5.60 of July 22, 1990.  Check with your vendor
        for information on configuration upgrades.  Also check your anonymous
        FTP configuration.  It is important to follow the instructions provided
        with the operating system to properly configure the files and
        directories available through anonymous FTP (for example, file and
        directory permissions, ownership and group).  Note that you should
        not use your system's standard password file or group file as the
        password file or group file for FTP.  The anonymous FTP root directory
        and its two subdirectories, etc and bin, should not be owned by ftp.


    6.  Fingerd hole used by the Morris Internet worm

        Make sure that you're running a version of finger that is more recent
        than November 1988.  Numerous Berkeley-derived versions of UNIX were
        vulnerable.


    7.  Inappropriate network configuration file entries

        Several vendors supply /etc/hosts.equiv files with a '+' (plus sign)
        entry.  The '+' entry should be removed from this file because it means
        that your system will trust all other systems.  Other files that
        should not contain a '+' entry include /etc/hosts.lpd and all ~/.rhost
        files on the system.  These files should not be world-writable.  We
        recommend that you do not support the following services in your
        /etc/inetd.conf file unless you specifically require them: 

                   port 11 - systat
                   port 69 - tftp
                   port 87 - link


    8.  Misconfiguration of uucp

        If your machine supports uucp, check the L.cmds (Permissions) file and
        ensure that only the commands you require are included. This file
        should be owned by root (not by uucp!) and world-readable.  The L.sys
        (Systems) file should be owned by uucp and protected (600) so that
        only programs running setuid uucp can access it.


    9.  Inappropriate 'secure' settings in /etc/ttys and /etc/ttytab

        Check the file /etc/ttys or /etc/ttytab depending on the release of
        UNIX being used.  The default setting should be that no terminal lines,
        pseudo terminals or network terminals are set secure except for the
        console.


   10.  Inappropriate entries in /usr/lib/aliases

        Examine the /usr/lib/aliases (mail alias) file for inappropriate
        entries.  Some alias files include an alias named 'uudecode' or just
        'decode'.  If this alias exists on your system, and you are not
        explicitly using it, then it should be removed.


   11.  Inappropriate file and directory protections

        Check your system documentation to establish the correct file and
        directory protections and ownership for system files and directories.
        In particular, check the '/' (root) and '/etc' directories, and all
        system and network configuration files.  Examine file and directory
        protections before and after installing software or running
        verification utilities.  Such procedures can cause file and directory
        protections to change.


   12.  Old versions of system software

        Older versions of operating systems often have security
        vulnerabilities that are well known to intruders.  To minimize your
        vulnerability to attacks, keep the version of your operating system
        up-to-date and apply security patches appropriate to your system(s) as
        soon as they become available.


C.  VMS System Vulnerabilities

    1.  Accounts with known default passwords

        Intruders often exploit system default passwords that have not been
        changed since installation.  Make sure to change all default passwords
        when the software is installed.  Be aware that product upgrades can
        quietly change account passwords to a new default.  It is best to
        change the passwords of default accounts after updates are applied.
        Accounts no longer in use should be removed from the authorization
        file and rights database.  Dormant accounts should be set to DISUSER.

        Intruders also try guessing simple user passwords.  See the discussion
        on weak passwords in Section A for suggestions on choosing good
        passwords.


    2.  Unauthorized versions of system files

        If an intruder gets into a system, the programs patch.exe,
        loginout.exe, and show.exe are often modified.  Compare these programs
        with those found in your distribution media.


D.  Software Tools To Assist In Securing Your System

 *****************************************************************************
 *  The CERT/CC will not formally review, evaluate, or endorse the tools     *
 *  and techniques described.  The decision to use the tools and             *
 *  techniques described is the responsibility of each user or               *
 *  organization, and we encourage each organization to thoroughly evaluate  *
 *  new tools and techniques before installation or use.                     *
 *****************************************************************************

    1.  Shadow passwords

        If your UNIX system has a shadow password capability, you should
        consider using it.  Under a shadow password system the /etc/passwd
        file does not have encrypted passwords in the password field.  Instead
        the encrypted passwords are held in a shadow file that is not world
        readable.  Consult your system manuals to determine whether a shadow
        password capability is available on your system, and to get details of
        how to set up and manage such a facility.


    2.  COPS (The Computer Oracle and Password System)

        COPS is a publicly available collection of programs that attempt to
        identify security problems in a UNIX system.  COPS does not attempt to
        correct any discrepancies found; it simply produces a report of its
        findings.  COPS was written by Dan Farmer and is available via
        anonymous FTP from the cert.sei.cmu.edu system (192.88.209.5) in the
        /pub/cops directory and via uucp from uunet.uu.net.


    3.  passwd+

        passwd+ is a replacement program suite that allows a system
        administrator to enforce policies for selecting passwords.  The suite
        also provides a logging capability.  passwd+ was written by Matt
        Bishop and can be obtained by anonymous FTP from the dartmouth.edu
        system (129.170.16.4) in the file /pub/passwd+.tar.Z.  Please read the
        README.IMPORTANT file which accompanies this software distribution.


    4.  TCP/IP Wrapper Program

        This program provides additional network logging information and gives
        a system administrator the ability to deny or allow access from certain
        systems or domains to the host on which the program is installed.
        Installation of this software does not require any modification to
        existing network software or network configuration files.
        The program was written by Wietse Venema from Eindhoven University of
        Technology in the Netherlands and is available via anonymous FTP from
        the cert.sei.cmu.edu system (192.88.209.5) in the file
        /pub/network_tools/tcp_wrapper.shar. 


-------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC via
telephone or e-mail.

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:

      CERT/CC personnel answer 7:30a.m. to 6:00p.m. EST(GMT-5)/EDT(GMT-4),
      and are on call for emergencies during other hours.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

--------------------------------------------------------------------------

**************************************************************************
*                                                                        *
*  Additionally, if you are a DDN user and you believe that your system  *
*  has been compromised, you need to contact the DDN Security            *
*  Coordination Center (SCC) via telephone or e-mail.                    *
*                                                                        *
*     E-mail address: SCC@NIC.DDN.MIL                                    *
*     Telephone: 1-(800) 365-3642                                        *
*                                                                        *
*  NIC help desk personnel answer 7:00 a.m. to 7:00 p.m. EST(GMT-5)      *
*  Monday through Friday except holidays.                                *
*                                                                        *
**************************************************************************

**************************************************************************
Security Bulletin 9125                  DISA Defense Communications System
9 December 1991             Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN is distributed  by the  DDN SCC  (Security
Coordination Center) under DISA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.112.36.5]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9125).
**************************************************************************

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center  distribution  system  as a  means  of        !
!     providing  DDN subscribers with useful security information.      !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

===========================================================================
CA-91:21                     CERT Advisory
                            December 6, 1991
		           SunOS NFS Jumbo and fsirand Patches

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC)
has received information concerning several vulnerabilities in Sun
Microsystems, Inc. (Sun) Network File System (NFS) and the fsirand
program. These vulnerabilities affect SunOS versions 4.1.1, 4.1, and
4.0.3 on all architectures.

Sun has provided separate patches for these vulnerabilities for SunOS
4.1.1, and has provided an initial patch for SunOS 4.1.  Sun will be
providing complete patches for 4.1 and 4.0.3 at a later date.  On
SunOS 4.1.1 systems, Sun states that patch 100173-07 must be installed
before patch 100424-1.  The patches are available through your local
Sun Answer Centers worldwide as well as through anonymous ftp from the
ftp.uu.net (192.48.96.2) system in the /sun-dist directory.

Fix                        PatchID        Filename            Checksum
NFS Jumbo 4.1.1            100173-07      100173-07.tar.Z     07044   209
NFS Jumbo 4.1              100121-08      100121-08.tar.Z     61464   287
fsirand 4.1.1              100424-01      100424-01.tar.Z     63070    50

Please note that Sun will occasionally update patch files.  If you
find that the checksum is different please contact Sun or the CERT/CC
for verification.

Sun recommends that sites upgrade to SunOS 4.1.1 to benefit from the
security improvements.  In addition, they recommend the installation
of all security-related patches applicable to the version of SunOS
that you are running.

A general NFS security note: due to security flaws in the protocol,
the CERT/CC recommends filtering SunRPC and NFS IP packets (sockets
111 and 2049) between the local network and the Internet.  This will
prevent intruders outside your local network from accessing your
files.

---------------------------------------------------------------------------

NFS Jumbo Patch, SunOS 4.1.1

I.   Description

This patch fixes several SunOS NFS bugs (not all security-related).
The patch file, 100173-08.tar.Z, contains fixes for SunOS version
4.1.1.  The BugIDs fixed in this patch are:

1039977 1032959 1029628 1037476 1038302 1034328 1045536 1030884 1045993
1047557 1052330 1053679 1041409 1065361 1066287 1064433 1070654

See the README file provided with the patch for more information.
 
II.  Impact

These vulnerabilities (and bugs) have multiple impacts, including
crashing the system, allowing unauthorized system access, and causing
a problem with file group ownership.

III. Solution

Obtain the patch from Sun or from ftp.uu.net and install, following
the provided instructions, with the following exception:

line 112 of the README file currently reads:

    mv /sys/`arch -k`/OBJ/nfs_subr.o /sys/arch -k`/OBJ/nfs_subr.o.FCS
                                          ^^^^^^^^
it should read:

    mv /sys/`arch -k`/OBJ/nfs_subr.o /sys/`arch -k`/OBJ/nfs_subr.o.FCS
                                          ^^^^^^^^^
(Note the one-character difference.)
        
---------------------

NFS Jumbo Patch, SunOS 4.1

I.   Description

This patch fixes several SunOS NFS bugs (not all security-related).
The patch file, 100121-08.tar.Z, contains fixes for SunOS version 4.1.
The BugIDs fixed in this patch are:

1026933 1034007 1039977 1029628 1037476 1038327 1038302
1034328 1045536 1045993 1047557 1030884 1052330 1053679

See the README file provided with the patch for more information.
 
II.  Impact

These vulnerabilities (and bugs) have multiple impacts, including
crashing the system, allowing unauthorized system access, and causing
a problem with file group ownership.

III. Solution

Obtain the patch from Sun or from ftp.uu.net and install, following
the provided instructions.
        
---------------------

fsirand, SunOS 4.1.1

I.   Description

A security vulnerability exists in SunOS NFS relating to the way in
which it allocates file handles.  The patch file, 100424-01.tar.Z,
contains a fix for SunOS version 4.1.1.  The BugID fixed in this patch
is 1063470.

II.  Impact

The fsirand program could allow a remote system user to guess NFS file
handles, thereby potentially allowing them to mount and access your
NFS file systems.

III. Solution 
        
Obtain the patch from Sun or from ftp.uu.net and install, following
the provided instructions.  You must install PatchID 100173-07 before
installing this patch.

---------------------------------------------------------------------------
The CERT/CC wishes to thank Bob Drzyzgula of the Federal Reserve Board,
Leendert van Doorn of Vrije University, and Wietse Venema of Eindhoven
University for their assistance.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC via
telephone or e-mail.

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:
           CERT/CC personnel answer 7:30a.m.-6:00p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories and other information related to computer security are
available for anonymous ftp from the cert.sei.cmu.edu (192.88.209.5)
system.
**************************************************************************
Security Bulletin 9126                  DISA Defense Communications System
19 December 1991            Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN is distributed  by the  DDN SCC  (Security
Coordination Center) under DISA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.112.36.5]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9126).
**************************************************************************

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center  distribution  system  as a  means  of        !
!     providing  DDN subscribers with useful security information.      !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

===========================================================================
CA-91:22                     CERT Advisory
                           December 16, 1991
                     SunOS OpenWindows V3.0 Patch
---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning a vulnerability in Sun Microsystems,
Inc. (Sun) OpenWindows version 3.0.  This vulnerability exists on all
sun4 and sun4c architectures running SunOS 4.1.1.

Sun has provided a patch for this vulnerability.  It is available
through your local Sun Answer Center as well as through anonymous ftp
from the ftp.uu.net (192.48.96.2) system in the /sun-dist directory.

Fix                     PatchID        Filename            Checksum
loadmodule              1076118        100448-01.tar.Z     04354  5

Please note that Sun will occasionally update patch files.  If you
find that the checksum is different please contact Sun or the CERT/CC
for verification.

---------------------------------------------------------------------------

I.   Description

     An OpenWindows, version 3, setuid program (loadmodule(8)) can be
     exploited to execute a user's program using the effective UID of root.


II.  Impact

     This vulnerability allows a local user to gain root access.


III. Solution

     Obtain the patch from Sun or from ftp.uu.net and install, following the
     provided instructions.

     As root:

     1. Move the existing loadmodule aside.

        # mv $OPENWINHOME/bin/loadmodule $OPENWINHOME/bin/loadmodule.orig
        # chmod 400 $OPENWINHOME/bin/loadmodule.orig

     2. Copy the new loadmodule into the OpenWindows bin directory.

        # cp sun4/loadmodule $OPENWINHOME/bin/loadmodule
        # chown root $OPENWINHOME/bin/loadmodule
        # chmod 4755 $OPENWINHOME/bin/loadmodule

     See the README file provided with the patch for more information.
---------------------------------------------------------------------------
The CERT/CC wishes to thank Ken Pon at Sun Microsystems, Inc. for alerting
us to this vulnerability.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC via
telephone or e-mail.

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 24-hour hotline:
           CERT/CC personnel answer 7:30a.m.-6:00p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories and other information related to computer security are
available for anonymous ftp from the cert.sei.cmu.edu (192.88.209.5)
system.
**************************************************************************
Security Bulletin 9201                  DISA Defense Communications System
January 22,1992             Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN is distributed  by the  DDN SCC  (Security
Coordination Center) under DISA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.112.36.5]
using login="anonymous" and password="guest".  The bulletin pathname is
SCC:DDN-SECURITY-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. SCC:DDN-SECURITY-9201).
**************************************************************************

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center  distribution  system  as a  means  of        !
!     providing  DDN subscribers with useful security information.      !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

===========================================================================
CA-92:01                        CERT Advisory
                              January 20, 1992
                     NeXTstep Configuration Vulnerability

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC)  
has received information concerning a vulnerability in release 2 of
NeXTstep's NetInfo default configuration.  This vulnerability will
be corrected in future versions of NeXTstep.

---------------------------------------------------------------------------

I.   Description

     By default, a NetInfo server process will provide information to
     any machine that requests it.


II.  Impact

     Remote users can gain unauthorized access to the network's
     administrative information such as the passwd file.


III. Solution

     Ensure that the trusted_networks property of each NetInfo domain's
     root NetInfo directory is set correctly, so that only those systems
     which should be obtaining information from NetInfo are granted
     access. The value for the trusted_networks property should be the
     network numbers of the networks the server should trust.

     Note that improperly setting trusted_networks can render your
     network unusable.

     Consult Chapter 16, "Security", of the "NeXT Network and System
     Administration" manual for release 2 for details on setting the
     trusted_networks property of the root NetInfo directory.

---------------------------------------------------------------------------
The CERT/CC wishes to thank NeXT Computer, Inc. for their cooperation in
documenting and publicizing this security vulnerability.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC via
telephone or e-mail.

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 (24-hour hotline)
           CERT/CC personnel answer 7:30a.m.-6:00p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories and other information related to computer security are
available for anonymous ftp from the cert.sei.cmu.edu (192.88.209.5) system.


**************************************************************************
Security Bulletin 9202                  DISA Defense Communications System
23 January 1992             Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
Coordination Center) under DISA contract as a means of communicating
information on network and host security exposures, fixes, and concerns
to security and management personnel at DDN facilities.  Back issues may
be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
using login="anonymous" and password="guest".  The bulletin pathname is
scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. scc/ddn-security-9201).
**************************************************************************

    First, we at the SCC hope you had a safe, secure, and happy new
    year.  

    For some time now, the SCC has produced daily reports on TAC
    activity and suspected TAC Security Incidents.  It has only
    been recently, however, that the SCC has been tasked by the DDN
    Network Security Officer (NSO) to perform follow-up on these
    suspected TAC Security Incidents with the user's Host
    Administrator (HA).  As a result, HA's are now receiving a
    portion of the Security Incident Report as it applies to their
    user(s).  The HA's are being asked to investigate these 
    suspected security incidents and respond back to the SCC with
    the results of their inquiries.  If a breach of DDN/TAC security
    has occurred, that user's TAC card will be deactivated.  If the HA
    fails to respond, it will also cause that user's TAC card to be
    deactivated.  The following acts are considered a breach of DDN/TAC
    security.

          Allowing your TAC access code to be used by anyone
          except yourself.

          Imbedding TAC access codes in software.

          Including TAC access codes in login files or scripts.

          Logging into a TAC for someone else.

    The TAC access codes are to be manually entered every time a user
    logs into the TAC.  HA's can request TAC cards for anyone who has
    a genuine need to utilize the network.  HA's can also request
    guest TAC cards for temporary users and for users who are waiting
    for their own TAC cards to arrive.  In 1992, let's make the DDN
    more secure than it has ever been before.
**************************************************************************
Security Bulletin 9203                  DISA Defense Communications System
February 4, 1992            Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN  SECURITY BULLETIN is distributed  by the  DDN SCC  (Security
Coordination Center) under DISA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [192.112.36.5]
using login="anonymous" and password="guest".  The bulletin pathname is
scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g., scc/ddn-security-9203).
**************************************************************************

                        REGISTRATION OF TAC USERS

      On 21 October 91, the Defense Information Systems Agency
      (DISA) published DDN Security Bulletin 9120, which discussed a
      problem with the timeliness of TAC users being re-registered
      with the Network Information Center (NIC).  This problem
      surfaced as a result of MILNET hosts being deconfigured and
      moved behind concentrators/gateways.  In Security Bulletin
      9120, the 15th of December had been set as the date the NIC
      was to terminate network access to all TAC users utilizing
      TAC cards registered to deconfigured hosts that had previously
      been direct-connected to the DDN.

      The purpose of this bulletin is to advise all concerned that
      the 15 December 91 termination date has been extended.  The
      reason for this decision is simple--there was not enough
      time to clear the logjam of users requiring re-registration
      processing both at the MILDEP level and at the NIC.  The
      process of re-registering TAC users who now fall behind
      concentrators/gateways had become a difficult and convoluted
      problem.  However, DISA and the Military Departments have had
      several meetings on this issue and have come to agreement on
      how to solve the problem long-term.  Therefore, once new
      registration procedures are implemented and re-registration
      is moving smoothly, a new termination date for TAC cards
      issued under the "old" deconfigured hosts will be set.
      This will probably occur within the next few months and will
      be done in conjunction with the annual re-registration 
      process.

      If there are any questions, please contact Major Boyd at
      Comm (703) 692-7580 or DSN 222-7580, e-mail to SCC@nic.ddn.mil. 


**************************************************************************
Security Bulletin 9205                  DISA Defense Communications System
February 18, 1992           Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
Coordination Center) under DISA contract as a means of communicating
information on network and host security exposures, fixes, and concerns
to security and management personnel at DDN facilities.  Back issues may
be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
using login="anonymous" and password="guest".  The bulletin pathname is
scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g., scc/ddn-security-9205).
**************************************************************************

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center  distribution  system  as a  means  of        !
!     providing  DDN subscribers with useful security information.      !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

===========================================================================
CA-92:03                        CERT Advisory
                              February 17, 1992
                          Internet Intruder Activity

---------------------------------------------------------------------------
   
   The Computer Emergency Response Team/Coordination Center (CERT/CC) has
   received information regarding a significant intrusion incident on the
   Internet.  Systems administrators should be aware that many systems on
   the Internet have been compromised due to this activity.  To identify
   whether your systems have been affected by the activity, we recommend
   that all system administrators check for the signs of intrusion
   detailed in this advisory.
   
   This advisory describes the activities that have been identified as
   part of this particular incident.  This does not address the
   possibility that systems may have been compromised due to other,
   unrelated intrusion activity.

---------------------------------------------------------------------------

I.   Description

     The intruders gained initial access to a host by discovering a
     password for a user account on the system.  They then attempted
     to become root on the compromised system.

II.  Impact

     Having gained root access on a system, the intruders installed
     trojan binaries that captured account information for both
     local and remote systems.  They also installed set-uid root
     shells to be used for easy root access.

III. Solution 

     A. Check your systems for signs of intrusion due to this incident.

        1. Check the su, ftpd, and ftp binaries (for example, "/bin/su",
           "/usr/ucb/ftp" and "/usr/etc/in.ftpd" on Sun systems)
           against copies from distribution media.

        2. Check for the presence of any of the following files:
           "/usr/etc/..." (dot dot dot), "/var/crash/..." (dot dot dot), 
           "/usr/etc/.getwd", "/var/crash/.getwd", or 
           "/usr/kvw/..." (dot dot dot).

        3. Check for the presence of "+" in the "/etc/hosts.equiv" file.

        4. Check the home directory for each entry in the "/etc/passwd"
           file for the presence of a ".rhosts" file containing
           "+ +" (plus space plus).

        5. Search the system for the presence of the following set-uid
           root files: "wtrunc" and ".a".

        6. Check for the presence of the set-uid root file "/usr/lib/lpx".


     B. Take the following steps to secure your systems.

        1. Save copies of the identified files to removable media.

        2. Replace any modified binaries with copies from
           distribution media.

        3. Remove the "+" entry from the "/etc/hosts.equiv" file and 
           the "+ +" (plus space plus) entry from any ".rhosts" files.

        4. Remove any of the set-uid root files that you find, which are
           mentioned in A5 or A6 above.

        5. Change every password on the system.

        6. Inspect the files mentioned in A2 above for references
           to other hosts.

---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC or
your representative in FIRST (Forum of Incident Response and Security Teams).

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 (24-hour hotline)
           CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

   Computer Emergency Response Team/Coordination Center (CERT/CC)
   Software Engineering Institute
   Carnegie Mellon University
   Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous ftp
from cert.sei.cmu.edu (192.88.209.5).


**************************************************************************
Security Bulletin 9206                  DISA Defense Communications System
February 24, 1992           Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
Coordination Center) under DISA contract as a means of communicating
information on network and host security exposures, fixes, and concerns
to security and management personnel at DDN facilities.  Back issues may
be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5] using 
login="anonymous" and password="guest".  The bulletin pathname is
scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g., scc/ddn-security-9206).
**************************************************************************

                     New Macintosh Virus Discovered

Virus: MBDF A
Damage: minimal, but see below
Spread: may be significant
Systems affected:  Apple Macintosh computers.  The virus spreads on 
                   all types of systems except MacPlus systems and
                   (perhaps) SE systems; however, it may be present 
                   on MacPlus and SE systems and not spread.

A new virus, currently named "MBDF A", has been discovered on Apple
Macintosh computer systems.  The virus does not intentionally cause
damage, but it does spread widely.  Instances of the virus have been
found at a number of sites worldwide.

The virus has been discovered in games at several archive sites.
At those sites, the games "Obnoxious Tetris" and "Ten Tile Puzzle" are
definitely infected.  It is possible that other files may be infected
at some archive sites.  You should be especially suspicious of any games
named "tetris-rotating" or "Tetricycle".  

The virus does not necessarily exhibit any symptoms on infected
systems.  Some abnormal behavior has been reported that may possibly be
traced to the virus.  These include Mac crashes and malfunctions in 
various programs.

Some specific symptoms include:

    * Infected Claris applications will indicate that they have
      been altered and will refuse to run.

    * The "BeHierarchic" shareware program ceases to work correctly.

    * Some programs will crash if something in the menu
      bar is selected with the mouse.

The virus works under both System 6 and System 7.

If you have downloaded any files from an archive site recently,
especially games, please do not use them or distribute copies of them
to anyone else until you are certain they are not infected.
Furthermore, we very strongly recommend that you DO NOT get any files
from the archive sites until the moderators at those sites have had an
opportunity to remove any infected files.

Currently, the virus is not found by (or evades) most anti-virus
tools.  Authors of all the major Macintosh anti-virus tools --
including commerical products such as SAM, Rival and Virex, and
shareware and freeware programs such as Disinfectant, Gatekeeper, and
Virus Detective -- have been informed of this new virus.  All are
planning to release updates to their software within the next few
days.  These releases will be through the normal distribution
channels.

Specific information on some of these products follows:
 
    Tool: Disinfectant
    Revision to be released: 2.6
    Where to find: usual archive sites and bulletin boards --
                   ftp.acns.nwu.edu, sumex-aim.stanford.edu,
                   rascal.ics.utexas.edu, AppleLink, 
                   America Online, CompuServe, Genie, Calvacom,
                   MacNet, Delphi, comp.binaries.mac
    When available: (expected) late 2/21/92

    Tool: Rival
    Revision to be released: 1.1.10
    Where to find it: AppleLink, America Online, Internet, Compuserve.
    When available: 2/21/92
    Other info: The only change with 1.1.9 is the ability to detect
                this vaccine (MBDF A).

    Tool: Virex INIT and application
    Revision to be released: 3.6 (for both products)
    Where to find: Microcom, Inc (919) 490-1277
    When available: User definable virus string available 2/21/92
                    3.6 versions available 2/24/92
    Comments:
    Virex 3.6 (app and INIT) will detect and repair the virus.  All
    Virex subscribers will automatically be sent an update on
    diskette.  All other registered users will receive a notice with
    information on how to update prior versions so that they will 
    be able to detect MBDF.  This information is also available on 
    Microcom's BBS.  (919)419-1602.

    Tool: Virus Detective
    Revision to be released: 5.0.1
    Where to find: Usual bulletin boards will announce a new search
                   string.  Registered users will also get a mailing 
                   with the new search string.
    When available: now (2/20/92) 
    Comments: search string is 
              "Resource MBDF & ID=0 & WData A9ABA146*4446#4A9A0"


Special thanks to the people at Claris who included self-check code
in their Macintosh software products.  Their foresight resulted in
an early detection of the virus and has thus helped the entire Mac
community.  We strongly encourage other vendors to consider doing the
same with their products.

The SCC wishes to acknowledge Mr. Gene Spafford of Purdue University
as the author of this document.

****************************************************************************

The point of contact for MILNET security-related incidents is the
Security Coordination Center (SCC).

E-mail address: SCC@NIC.DDN.MIL

Telephone: 1-(800)-365-3642
           NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,
           Monday through Friday except on federal holidays.

****************************************************************************



**************************************************************************
Security Bulletin 9207                  DISA Defense Communications System
February 26, 1992           Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
Coordination Center) under DISA contract as a means of communicating
information on network and host security exposures, fixes, and concerns
to security and management personnel at DDN facilities.  Back issues may
be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5] using
login="anonymous" and password="guest".  The bulletin pathname is
scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g., scc/ddn-security-9207).
**************************************************************************

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT) and is being relayed unedited      !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center distribution system as a means of providing   !
!     DDN subscribers with useful security information.                 !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

===========================================================================
CA-92:04                        CERT Advisory
                              February 25, 1992
                       AT&T /usr/etc/rexecd Vulnerability 

---------------------------------------------------------------------------
  
  The Computer Emergency Response Team/Coordination Center (CERT/CC) has
  received information concerning a 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).
  
  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.
  
  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.
  
---------------------------------------------------------------------------
  
  I.   Description
       
       A vulnerability has been identified where root privileges may be
       accessed through the use of /usr/etc/rexecd.
  
  II.  Impact
  
       A user on a remote machine may be able to run commands as root on
       the target host (the host running the affected /usr/etc/rexecd).
  
  III. Solution
  
       1. 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
  
       2. 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 to replace the existing /usr/etc/rexecd binary.
  
---------------------------------------------------------------------------
  The CERT/CC wishes to thank Bradley E. Smith, Network & Technical Services,
  Bradley University, for bringing this vulnerability to our attention and for
  providing a corresponding solution.  We would also like to thank AT&T for
  their very quick response to this problem.
---------------------------------------------------------------------------
  
  If you believe that your system has been compromised, contact CERT/CC or
  your representative in FIRST (Forum of Incident Response and Security Teams).
  
  Internet E-mail: cert@cert.sei.cmu.edu
  Telephone: 412-268-7090 (24-hour hotline)
             CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
             on call for emergencies during other hours.
  
  Computer Emergency Response Team/Coordination Center (CERT/CC)
  Software Engineering Institute
  Carnegie Mellon University
  Pittsburgh, PA 15213-3890
  
  Past advisories, information about FIRST representatives, and other
  information related to computer security are available for anonymous ftp
  from cert.sei.cmu.edu (192.88.209.5).
  
  
****************************************************************************
  
  The point of contact for MILNET security-related incidents is the
  Security Coordination Center (SCC).
  
  E-mail address: SCC@NIC.DDN.MIL
  
  Telephone: 1-(800)-365-3642
       NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,
       Monday through Friday except on federal holidays.
  
****************************************************************************
**************************************************************************
Security Bulletin 9209                  DISA Defense Communications System
March 19, 1992              Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

  The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
  Coordination Center) under DISA contract as a means of communicating
  information on network and host security exposures, fixes, and concerns
  to security and management personnel at DDN facilities.  Back issues may
  be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  using login="anonymous" and password="guest".  The bulletin pathname is
  scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  and "nn" is a bulletin number, e.g. scc/ddn-security-9209).
**************************************************************************
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center  distribution  system  as a  means  of        !
!     providing  DDN subscribers with useful security information.      !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

===========================================================================
CA-92:06                        CERT Advisory
                               March 19, 1992
                           AIX uucp Vulnerability

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning a vulnerability with the UUCP software
in versions of AIX up to 2007.  The vulnerability does not exist in AIX 3.2.

IBM is aware of this problem, and a fix is available as apar number
"ix18516".  This patch is available for all AIX releases from GOLD to
2006.

The fix is in the 2007 update and 3.2 release of AIX.  IBM customers may
call IBM Support (800-237-5511) and ask that the fix be shipped to them.
Patches may be obtained outside the U.S. by contacting your local IBM
representative.

---------------------------------------------------------------------------

I.   Description

     Previous versions, except AIX 3.2, of the UUCP software contained
     incorrectly configured versions of various files.


II.  Impact

     Local users can execute unauthorized commands and gain unauthorized
     root access.


III. Solution

     - If allowing users access to the uucp isn't necessary, disable it.

       % chmod 0100 /usr/bin/uucp

     - Obtain the fix from IBM Support.

     - Install the fix following the instructions in the README file.

---------------------------------------------------------------------------
The CERT/CC would like to thank Steve Knodle, Clarkson University, for
bringing this security vulnerability to our attention.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC or
your representative in FIRST (Forum of Incident Response and Security Teams).

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 (24-hour hotline)
           CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous ftp
from cert.sei.cmu.edu (192.88.209.5).


****************************************************************************
*                                                                          *
*    The point of contact for MILNET security-related incidents is the     *
*    Security Coordination Center (SCC).                                   *
*                                                                          *
*               E-mail address: SCC@NIC.DDN.MIL                            *
*                                                                          *
*               Telephone: 1-(800)-365-3642                                *
*                                                                          *
*    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
*    Monday through Friday except on federal holidays.                     *
*                                                                          *
****************************************************************************

From varallob Thu Mar 19 14:24:05 1992
Return-Path: <varallob>
Received: by nic.ddn.mil (4.1/SMI-4.1)
	id AA01539; Thu, 19 Mar 92 14:24:05 EST
From: varallob (Barbara Varallo)
Message-Id: <9203191924.AA01539@nic.ddn.mil>
Subject: Security Bulletin 9209
To: bobm (Bob McCollum), richm (Rich Meinheit)
Date: Thu, 19 Mar 92 14:24:04 EST
X-Mailer: ELM [version 2.3 PL11]
Status: OR

Bob--

Please load this as soon as you can.  Rich, I didn't change anything
but the header format.

Barb


**************************************************************************
Security Bulletin 9209                  DISA Defense Communications System
March 19, 1992              Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

  The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
  Coordination Center) under DISA contract as a means of communicating
  information on network and host security exposures, fixes, and concerns
  to security and management personnel at DDN facilities.  Back issues may
  be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  using login="anonymous" and password="guest".  The bulletin pathname is
  scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  and "nn" is a bulletin number, e.g. scc/ddn-security-9209).
**************************************************************************
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center  distribution  system  as a  means  of        !
!     providing  DDN subscribers with useful security information.      !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

===========================================================================
CA-92:06                        CERT Advisory
                               March 19, 1992
                           AIX uucp Vulnerability

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning a vulnerability with the UUCP software
in versions of AIX up to 2007.  The vulnerability does not exist in AIX 3.2.

IBM is aware of this problem, and a fix is available as apar number
"ix18516".  This patch is available for all AIX releases from GOLD to
2006.

The fix is in the 2007 update and 3.2 release of AIX.  IBM customers may
call IBM Support (800-237-5511) and ask that the fix be shipped to them.
Patches may be obtained outside the U.S. by contacting your local IBM
representative.

---------------------------------------------------------------------------

I.   Description

     Previous versions, except AIX 3.2, of the UUCP software contained
     incorrectly configured versions of various files.


II.  Impact

     Local users can execute unauthorized commands and gain unauthorized
     root access.


III. Solution

     - If allowing users access to the uucp isn't necessary, disable it.

		% chmod 0100 /usr/bin/uucp

     - Obtain the fix from IBM Support.

     - Install the fix following the instructions in the README file.

---------------------------------------------------------------------------
The CERT/CC would like to thank Steve Knodle, Clarkson University, for
bringing this security vulnerability to our attention.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC or
your representative in FIRST (Forum of Incident Response and Security Teams).

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 (24-hour hotline)
           CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous ftp
from cert.sei.cmu.edu (192.88.209.5).


****************************************************************************
*                                                                          *
*    The point of contact for MILNET security-related incidents is the     *
*    Security Coordination Center (SCC).                                   *
*                                                                          *
*               E-mail address: SCC@NIC.DDN.MIL                            *
*                                                                          *
*               Telephone: 1-(800)-365-3642                                *
*                                                                          *
*    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
*    Monday through Friday except on federal holidays.                     *
*                                                                          *
****************************************************************************


**************************************************************************
Security Bulletin 9210                  DISA Defense Communications System
March 19, 1992              Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
Coordination Center) under DISA contract as a means of communicating
information on network and host security exposures, fixes, and concerns
to security and management personnel at DDN facilities.  Back issues may
be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
using login="anonymous" and password="guest".  The bulletin pathname is
scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
and "nn" is a bulletin number, e.g. scc/ddn-security-9210).
**************************************************************************

              *** Macintosh INIT 1984 Virus Discovered ***

Virus: INIT 1984
Damage: high
Spread: minimal
Systems affected: Apple Macintosh computers. All types. 

A new virus, which has been designated "INIT 1984", has been
discovered on Apple Macintosh computer systems. This virus is designed
to trigger if an infected system is booted on any Friday the 13th in
1991 or later years. Damage from the virus includes changing the names
and attributes of a large number of folders and files to random
strings and the actual deletion of a small percentage (< 2%) of files.

The virus infects only system extensions of type "INIT" (also known as
"startup documents"). It does not infect the System file, desktop
files, control panel files, applications, or document files. Because
INIT files are shared less frequently than are applications, and
because of the structure of the virus code, the INIT 1984 virus does
not spread as rapidly as most other viruses.

As of the date of this announcement (3/19/92), we have only a few
reported sightings of this virus, including one from a site in Europe
and one from a site in the USA. In both cases, the virus caused
significant damage when infected Macintoshes were restarted on Friday,
3/13/92. Because only a few reports of damage were received, we have
reason to believe that the virus is not widespread. However, it is
conceivable that this virus might have affected Macintosh systems on
Friday 9/13/91 or Friday 12/13/91 without being recognized as the
cause of the damage.  If you think you may have been a victim of this
virus in 1991, please contact me via e-mail at spaf@cs.purdue.edu.

The current versions of Gatekeeper and SAM Intercept (in advanced and
custom mode) are effective against this virus.  Either program should
generate an alert if the virus is present and attempts to spread to
other files.

The virus affects all types of Macintosh computers. It spreads and
attacks under both System 6 and System 7. On very old Macintoshes
(those with the 64K ROMs), the virus will cause crashes at boot time.

Authors of all major Macintosh anti-virus tools are planning updates
to their tools to locate and/or eliminate this virus. Some of these
are listed below. We recommend that you obtain and run an updated
version of at least one of these programs.

Some specific information on updated Mac anti-virus products follows:

    Tool: Disinfectant
    Status: Free software (courtesy of Northwestern University and
            John Norstad)
    Revision to be released: 2.7
    Where to find: usual archive sites and bulletin boards --
                   ftp.acns.nwu.edu, sumex-aim.stanford.edu,
                   rascal.ics.utexas.edu, AppleLink, America Online,
                   CompuServe, Genie, Calvacom, MacNet, Delphi,
                   comp.binaries.mac
    When available: (expected) 3/18/92


    Tool: Gatekeeper
    Status: Free software (courtesy of Chris Johnson)
    Revision to be released: 1.2.5
    Where to find: usual archive sites and bulletin boards --
                   microlib.cc.utexas.edu, sumex-aim.stanford.edu,
                   rascal.ics.utexas.edu, comp.binaries.mac
    When available: (expected) 3/20/92


    Tool: Rival
    Status: Commercial software
    Revision to be released: INIT 1984 Vaccine
    Where to find it: AppleLink, America Online, Internet, Compuserve.
    When available: Immediately.


    Tool: SAM (Virus Clinic and Intercept)
    Status: Commercial software
    Revision to be released: 3.0.7
    Where to find: CompuServe, America Online, Applelink, Symantec's
                   Bulletin Board @ 408-973-9598
    When available: Immediately.  Version 3.0.7 of the Virus
                    Definitions file are also availble.


    Tool: Virex INIT
    Status: Commercial software
    Revision to be released: 3.7 
    Where to find: Microcom, Inc (919) 490-1277 
    When available: Immediately.
    Comments:
    Virex 3.7 will detect and repair the virus. All
    Virex subscribers will automatically be sent an update on
    diskette. All other registered users will receive a notice with
    information to update prior versions to be able to detect
    INIT-1984. This information is also available on Microcom's BBS.
    (919)419-1602, and is given below.

    Virus Name: INIT 1984    Guide Number: 5275840
    Virus Code: 0049  4E49  5410  07C0  96
                3008  1490  7710  002F  2C
                3C49  4E49  5400  0300  1E
                4AA9  AB55  4F81  8090  9A


    Tool: Virus Detective
    Status: Shareware
    Revision to be released: 5.0.3
    Where to find: Usual bulletin boards will announce a new search string.
                   Registered users will also get a mailing
                   with the new search string.
    When available: Immediately.
    Comments: search string is

Resource INIT & Size<4500 & WData 494E#EA994*4954#8A9AB ; For finding INIT1984


     The SCC wishes to acknowledge Mr. Gene Spafford of Purdue University
     as the author of this document.


  ****************************************************************************
  *                                                                          *
  *    The point of contact for MILNET security-related incidents is the     *
  *    Security Coordination Center (SCC).                                   *
  *                                                                          *
  *               E-mail address: SCC@NIC.DDN.MIL                            *
  *                                                                          *
  *               Telephone: 1-(800)-365-3642                                *
  *                                                                          *
  *    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
  *    Monday through Friday except on federal holidays.                     *
  *                                                                          *
  ****************************************************************************


**************************************************************************
Security Bulletin 9211                  DISA Defense Communications System
April 1, 1992               Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

  The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
  Coordination Center) under DISA contract as a means of communicating
  information on network and host security exposures, fixes, and concerns
  to security and management personnel at DDN facilities.  Back issues may
  be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  using login="anonymous" and password="guest".  The bulletin pathname is
  scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  and "nn" is a bulletin number, e.g. scc/ddn-security-9211).
**************************************************************************

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important advisory was issued by the Computer       !
!     Emergency Response Team (CERT) and is being relayed unedited      !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center distribution system as a means of providing   !
!     DDN subscribers with useful security information.                 !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

===========================================================================
CA-92:07                        CERT Advisory
                               March 31, 1992
                        AIX /bin/passwd Vulnerability

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning a vulnerability with the passwd command
in AIX 3.2 and the 2007 update of AIX 3.1.

IBM is aware of this problem, and a fix is available as apar number
"ix23505".  Patches are available for AIX 3.2 and the 2007 update of 
AIX 3.1.

This fix may be ordered from Level 2 support or by anonymous ftp from 
software.watson.ibm.com (129.34.139.5) on the Internet.

     1. To order from IBM, call 1-800-237-5511 and ask 
        that the fix be shipped.  Outside the U.S., you 
        may obtain patches by contacting your local IBM
        representative.

     2. If you are on the Internet, use anonymous ftp to obtain 
        the fix from software.watson.ibm.com.

        Patch           Filename                Checksum
        AIX 3.2         pub/aix3/pas.32.tar.Z   54431  2262
        AIX 3.1 2007    pub/aix3/pas.31.tar.Z   06703    99

        Patches should be retrieved using binary mode.


IBM is currently incorporating the fix into the 3.2 version and 3.1
updates of AIX.  Future shipments of these products should not be 
vulnerable to this problem.  If you have any questions about products 
you receive, please contact your IBM representative.
---------------------------------------------------------------------------

I.   Description

     The passwd command contains a security vulnerability.

II.  Impact

     Local users can gain unauthorized root access.

III. Solution

     A.  As root, disable /bin/passwd until you obtain and install 
         the patch.

                # chmod 0500 /bin/passwd

     B.  Obtain the fix from IBM and install according to the
         directions provided with the patch.

---------------------------------------------------------------------------
The CERT/CC would like to thank Paul Selick of the University of Toronto
for bringing this security vulnerability to our attention.  We would also 
like to thank IBM for their quick response to this problem, and for making 
the patches available via anonymous ftp.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC or
your representative in FIRST (Forum of Incident Response and Security Teams).

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 (24-hour hotline)
           CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous ftp
from cert.sei.cmu.edu (192.88.209.5).

****************************************************************************
*                                                                          *
*    The point of contact for MILNET security-related incidents is the     *
*    Security Coordination Center (SCC).                                   *
*                                                                          *
*               E-mail address: SCC@NIC.DDN.MIL                            *
*                                                                          *
*               Telephone: 1-(800)-365-3642                                *
*                                                                          *
*    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
*    Monday through Friday except on federal holidays.                     *
*                                                                          *
****************************************************************************

**************************************************************************
Security Bulletin 9213                  DISA Defense Communications System
April 27, 1992              Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

  The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
  Coordination Center) under DISA contract as a means of communicating
  information on network and host security exposures, fixes, and concerns
  to security and management personnel at DDN facilities.  Back issues may
  be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  using login="anonymous" and password="guest".  The bulletin pathname is
  scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  and "nn" is a bulletin number, e.g. scc/ddn-security-9213).
**************************************************************************
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center  distribution  system  as a  means  of        !
!     providing  DDN subscribers with useful security information.      !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
===========================================================================
CA-92:09                        CERT Advisory
                               April 27, 1992
                       AIX Anonymous FTP Vulnerability

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning a vulnerability in the anonymous FTP
configuration in all versions of AIX.

IBM is aware of this problem and a fix is available as apar number
"ix23944".  This patch is available for all AIX releases from "GOLD".

IBM customers may call IBM Support (800-237-5511) and ask that the fix
be shipped to them.  Patches may be obtained outside the U.S. by contacting 
your local IBM representative.  The fix will appear in the upcoming 2009 
update and the next release of AIX.

---------------------------------------------------------------------------

I.   Description

     Previous versions of the anonymous FTP installation script,
     /usr/lpp/tcpip/samples/anon.ftp, incorrectly configured various files
     and directories.
     

II.  Impact

     Remote users can execute unauthorized commands and gain access to the
     system if anonymous FTP has been installed.


III. Solution

     A.  Obtain the fix from IBM Support.  The fix contains three
         files: a "readme" file (README.a23944), the fix installation
         script (install.a23944), and an archive containing the updated
         files (PATCH.a23944.Z).

     B.  Install the fix following the instructions in the README file.

---------------------------------------------------------------------------
The CERT/CC would like to thank Charles McGuire of the Computer Science
Department, the University of Montana, for bringing this security
vulnerability to our attention and IBM for their response to the problem.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC or
your representative in FIRST (Forum of Incident Response and Security Teams).

Internet E-mail: cert@cert.sei.cmu.edu
Telephone: 412-268-7090 (24-hour hotline)
           CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous ftp
from cert.sei.cmu.edu (192.88.209.5).

Please note: cert.sei.cmu.edu is soon to become cert.org.

****************************************************************************
*                                                                          *
*    The point of contact for MILNET security-related incidents is the     *
*    Security Coordination Center (SCC).                                   *
*                                                                          *
*               E-mail address: SCC@NIC.DDN.MIL                            *
*                                                                          *
*               Telephone: 1-(800)-365-3642                                *
*                                                                          *
*    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
*    Monday through Friday except on federal holidays.                     *
*                                                                          *
****************************************************************************



**************************************************************************
Security Bulletin 9214                  DISA Defense Communications System
May 27, 1992                Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

  The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
  Coordination Center) under DISA contract as a means of communicating
  information on network and host security exposures, fixes, and concerns
  to security and management personnel at DDN facilities.  Back issues may
  be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  using login="anonymous" and password="guest".  The bulletin pathname is
  scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  and "nn" is a bulletin number, e.g. scc/ddn-security-9214).
**************************************************************************
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center  distribution  system  as a  means  of        !
!     providing  DDN subscribers with useful security information.      !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
===========================================================================
CA-92:10                        CERT Advisory
                                May 26, 1992
                          AIX crontab Vulnerability

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning a vulnerability in crontab(1) in version 3.2
of IBM's AIX operating system.

IBM is aware of this problem, and a fix is available as apar number "ix26997"
for AIX version 3.2.  The version information for the patched /usr/bin/crontab
is shown in the following what(1) output:

% what /usr/bin/crontab
04 1.23 com/cmd/cntl/cron/crontab.c, cmdcntl, bos320, 9218320f 4/8/92 11:50:42
07 1.8  com/cmd/cntl/cron/permit.c, bos, bos320 4/25/91 17:16:59
11 1.15  com/cmd/cntl/cron/cronsub.c, bos, bos320 8/18/91 20:42:32
06 1.9  com/cmd/cntl/cron/funcs.c, bos, bos320 6/8/91 21:22:40

If your crontab contains modules older than the above output indicates, we
suggest that you install the fix.

---------------------------------------------------------------------------

I.   Description

     The distributed version of /usr/bin/crontab contains a security
     vulnerability.
     

II.  Impact

     Local users can gain unauthorized root access to the system.


III. Solution

     The CERT/CC suggests that sites install the fix that IBM has made
     available.  As an interim step, we suggests that sites prevent all
     non-root users from running /usr/bin/crontab by removing (or renaming)
     the /var/adm/cron/cron.allow and /var/adm/cron/cron.deny files.

     - Obtain the fix from IBM Support.

          1. To order from IBM call 1-800-237-5511 and ask
             that the fix be shipped.  Outside the U.S., patches
             may be obtainedby contacting your local IBM
             representative.

          2. If you are on the Internet, use anonymous ftp to obtain
             the fix from software.watson.ibm.com (129.34.139.5).

             Patch           Filename                Checksum
             AIX 3.2         pub/aix3/cronta.tar.Z   02324   154

             You must use binary mode to retrieve the patch.

     - Install the fix following the instructions in the README file.

---------------------------------------------------------------------------
The CERT/CC would like to thank Fuat Baran of Advanced Network & Services,
Inc., for bringing this security vulnerability to our attention and IBM for
their quick response to this problem.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC or
your representative in FIRST (Forum of Incident Response and Security Teams).

Internet E-mail: cert@cert.org
Telephone: 412-268-7090 (24-hour hotline)
           CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous ftp
from cert.org (192.88.209.5).

****************************************************************************
*                                                                          *
*    The point of contact for MILNET security-related incidents is the     *
*    Security Coordination Center (SCC).                                   *
*                                                                          *
*               E-mail address: SCC@NIC.DDN.MIL                            *
*                                                                          *
*               Telephone: 1-(800)-365-3642                                *
*                                                                          *
*    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
*    Monday through Friday except on federal holidays.                     *
*                                                                          *
****************************************************************************

**************************************************************************
Security Bulletin 9215                  DISA Defense Communications System
May 27, 1992                Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

  The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
  Coordination Center) under DISA contract as a means of communicating
  information on network and host security exposures, fixes, and concerns
  to security and management personnel at DDN facilities.  Back issues may
  be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  using login="anonymous" and password="guest".  The bulletin pathname is
  scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  and "nn" is a bulletin number, e.g. scc/ddn-security-9215).
**************************************************************************
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center  distribution  system  as a  means  of        !
!     providing  DDN subscribers with useful security information.      !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
===========================================================================
CA-92:11                        CERT Advisory
                                May 27, 1992
            SunOS Environment Variables and setuid/setgid Vulnerability
---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning a vulnerability involving environment
variables and setuid/setgid programs under Sun Microsystems Computer
Corporation SunOS.  This vulnerability exists on all Sun architectures
running SunOS 4.0 and higher.

In-house and third-party software can also be impacted by this
vulnerability.  For example, the current versions of rnews, sudo,
smount, and npasswd are known to be vulnerable under SunOS.  See the
Description section of this advisory for details of how to identify
software which may be vulnerable.

The workaround detailed in this advisory can be used to protect
vulnerable software on SunOS operating system versions for which
patches are unavailable, or for local or third party software which
may be vulnerable.

Sun has provided patches for SunOS 4.1, 4.1.1, and 4.1.2 programs
which are known to be impacted by this vulnerability.  They are
available through your local Sun Answer Center as well as through
anonymous ftp from the ftp.uu.net (137.39.1.9) system in the
/systems/sun/sun-dist directory.

Fix                     PatchID        Filename            Checksum
login and su            100630-01      100630-01.tar.Z     36269    39
sendmail                100377-04      100377-04.tar.Z     14692   311

Note: PatchID 100630-01 contains the international version of
/usr/bin/login.  PatchID 100631-01 contains the domestic version
of /usr/bin/login and is only available from Sun Answer Centers for
sites that use the US Encryption Kit.

Please note that Sun will occasionally update patch files.  If you
find that the checksum is different please contact Sun or the CERT/CC
for verification.

---------------------------------------------------------------------------

I.   Description

     A security vulnerability exists if a set-user-id program changes
     its real and effective user ids to be the same (but not to the
     invoker's id), and subsequently causes a dynamically-linked program 
     to be exec'd.  A similar vulnerability exists for set-group-id programs.

     In particular, SunOS /usr/lib/sendmail, /usr/bin/login,
     /usr/bin/su, and /usr/5bin/su are vulnerable to this problem.

II.  Impact

     Local users can gain unauthorized privileged access to the system.

III. Solution
        
     A.  Obtain and install the patches from Sun or from ftp.uu.net following 
         the provided instructions.

     B.  The following workaround can be used to protect vulnerable binaries
         for which patches are unavailable for your SunOS version,
         or for local or third party software which may be vulnerable. 
         The example given is a workaround for /usr/lib/sendmail.  

         1.  As root, rename the existing version of /usr/lib/sendmail
             and modify the permissions to prevent misuse.

             # mv /usr/lib/sendmail /usr/lib/sendmail.dist
             # chmod 755 /usr/lib/sendmail.dist

         2.  In an empty temporary directory, create a file wrapper.c
             containing the following C program source (remember to
             strip any leading white-space characters from the #define lines).

             /* Start of C program source */

             /* Change the next line to reflect the full pathname
                of the file to be protected by the wrapper code   */

             #define COMMAND "/usr/lib/sendmail.dist"
             #define VAR_NAME "LD_"

             main(argc,argv,envp)
             int argc;
             char **argv;
             char **envp;
             {
                     register char  **cpp;
                     register char  **xpp;
                     register char   *cp;

                     for (cpp = envp; cp = *cpp;) {
                             if (strncmp(cp, VAR_NAME, strlen(VAR_NAME))==0) {
                                     for (xpp = cpp; xpp[0] = xpp[1]; xpp++);
                                     /* void */ ;
                             }
                             else {
                                     cpp++;
                             }
                     }

                     execv(COMMAND, argv);
                     perror(COMMAND);
                     exit(1);
             }
             /* End of C program source */

         3.  As root, compile the C program source for the wrapper and
             install the resulting binary.

             # make wrapper
             # mv ./wrapper /usr/lib/sendmail
             # chown root /usr/lib/sendmail
             # chmod 4711 /usr/lib/sendmail

         4.  Steps 1 through 3 should be repeated for other vulnerable
             programs with the appropriate substitution of pathnames and file
             names. The "COMMAND" C preprocessor variable within the C program
             source should also be changed to reflect the appropriate renamed
             system binary.

---------------------------------------------------------------------------
The CERT/CC wishes to thank the following for their assistance: CIAC,
PCERT, and in particular Wietse Venema of Eindhoven University, The
Netherlands, for his support in the analysis of and a workaround for
this problem.  We also wish to thank Sun Microsystems Computer
Corporation for their prompt response to this vulnerability.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC or
your representative in FIRST (Forum of Incident Response and Security Teams).

Internet E-mail: cert@cert.org
Telephone: 412-268-7090 (24-hour hotline)
           CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous ftp
from cert.org (192.88.209.5).

****************************************************************************
*                                                                          *
*    The point of contact for MILNET security-related incidents is the     *
*    Security Coordination Center (SCC).                                   *
*                                                                          *
*               E-mail address: SCC@NIC.DDN.MIL                            *
*                                                                          *
*               Telephone: 1-(800)-365-3642                                *
*                                                                          *
*    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
*    Monday through Friday except on federal holidays.                     *
*                                                                          *
****************************************************************************
**************************************************************************
Security Bulletin 9217                  DISA Defense Communications System
June 8, 1992                Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

  The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
  Coordination Center) under DISA contract as a means of communicating
  information on network and host security exposures, fixes, and concerns
  to security and management personnel at DDN facilities.  Back issues may
  be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  using login="anonymous" and password="guest".  The bulletin pathname is
  scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  and "nn" is a bulletin number, e.g. scc/ddn-security-9217).
**************************************************************************
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center  distribution  system  as a  means  of        !
!     providing  DDN subscribers with useful security information.      !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

===========================================================================
CA-92:13                       CERT Advisory
                               June 4, 1992
                          SunOS NIS Vulnerability
---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information concerning several vulnerabilities with NIS under
Sun Microsystems, Inc. SunOS.  These vulnerabilities exist in NIS under
SunOS 4.1, 4.1.1, and 4.1.2, and may or may not exist in earlier versions
of NIS.

Sun has provided fixes for SunOS 4.1, 4.1.1, and 4.1.2 for these
vulnerabilities.  The patch file containing these fixes is available
through your local Sun Answer Center and through anonymous ftp from
ftp.uu.net (137.39.1.9) in the /systems/sun/sun-dist directory.  Note
that these fixes will probably not be compatible with SunOS 4.0.3 and
earlier versions of the operating system.

Fix                              PatchID      Filename            Checksum
/usr/etc/{ypserv,ypxfrd,portmap} 100482-2     100482-02.tar.Z     53416   284

Please note that Sun will occasionally update patch files.  If you
find that the checksum is different, please contact Sun or the CERT/CC
for verification.

---------------------------------------------------------------------------

I.   Description

     A security vulnerability exists under NIS allowing unauthorized access
     to NIS information.

II.  Impact

     A user on a remote host can obtain copies of the NIS maps from a
     system running NIS.  The remote user can attempt to guess passwords
     for the system using the obtained NIS password map information.

III. Solution

     A.  Obtain and install the patch from Sun or from ftp.uu.net following
         the instructions provided in the "README" file.  

         1.  As root, rename the existing versions of
             /usr/etc/{ypserv,ypxfrd,portmap} and modify the
             permissions to prevent misuse.

             # mv /usr/etc/ypserv /usr/etc/ypserv.orig
             # mv /usr/etc/ypxfrd /usr/etc/ypxfrd.orig
             # mv /usr/etc/portmap /usr/etc/portmap.orig
             # chmod 0400 /usr/etc/ypserv.orig 
             # chmod 0400 /usr/etc/ypxfrd.orig
             # chmod 0400 /usr/etc/portmap.orig

         2.  Copy the new binaries into the /usr/etc directory.

             # cp `arch`/{4.1, 4.1.1, 4.1.2}/ypserv /usr/etc/ypserv
             # cp `arch`/{4.1, 4.1.1, 4.1.2}/ypxfrd /usr/etc/ypxfrd
             # cp `arch`/{4.1, 4.1.1, 4.1.2}/portmap /usr/etc/portmap
             # chown root /usr/etc/ypserv /usr/etc/ypxfrd /usr/etc/portmap
             # chmod 755 /usr/etc/ypserv /usr/etc/ypxfrd /usr/etc/portmap

         3.  Copy the securenets file to the /var/yp directory.  Any
             site that has an existing /var/yp/securenets file should 
             rename it prior copying the new version of the file.

             # cp `arch`/{4.1, 4.1.1, 4.1.2}/securenets /var/yp
             # chown root /var/yp/securenets
             # chmod 644 /var/yp/securenets

         4.  Edit the /var/yp/securenets file to reflect the correct
             configuration for your site.  See the "README" file for
             details of the file syntax and special instructions for
             hosts with multiple Ethernet interfaces.  The file should
             not contain any blank lines.
 
         5.  Reboot the system to invoke the new binaries.

---------------------------------------------------------------------------
The CERT/CC would like to thank Casper Dik of the University of Amsterdam,
The Netherlands, and Peter Lamb of the Division of Information Technology,
Commonwealth Scientific and Industrial Research Organization, Australia,
for their assistance.  We also wish to thank Sun Microsystems, Inc. for
their response to this vulnerability.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC or
your representative in FIRST (Forum of Incident Response and Security Teams).

Internet E-mail: cert@cert.org
Telephone: 412-268-7090 (24-hour hotline)
           CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous ftp
from cert.org (192.88.209.5).

****************************************************************************
*                                                                          *
*    The point of contact for MILNET security-related incidents is the     *
*    Security Coordination Center (SCC).                                   *
*                                                                          *
*               E-mail address: SCC@NIC.DDN.MIL                            *
*                                                                          *
*               Telephone: 1-(800)-365-3642                                *
*                                                                          *
*    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
*    Monday through Friday except on federal holidays.                     *
*                                                                          *
****************************************************************************
**************************************************************************
Security Bulletin 9218                  DISA Defense Communications System
June 23, 1992               Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

  The DDN SECURITY BULLETIN is distributed by the DDN Security
  Coordination Center (SCC) under DISA contract as a means of communicating
  information on network and host security exposures, fixes, and concerns
  to security and management personnel at DDN facilities.  Back issues may
  be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  using login="anonymous" and password="guest".  The bulletin pathname is
  scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  and "nn" is a bulletin number, e.g. scc/ddn-security-9218).
**************************************************************************
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important advisory was issued by the Computer       !
!     Emergency Response Team (CERT) and is being relayed unedited      !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center distribution system as a means of providing   !
!     DDN subscribers with useful security information.                 !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
===========================================================================
CA-92:14                        CERT Advisory
                                June 22, 1992
                        Altered System Binaries Incident

---------------------------------------------------------------------------

The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information regarding a series of significant intrusion
incidents on the Internet.  Systems administrators should be aware
that many systems on the Internet have been compromised due to this
activity.  To identify whether your systems have been affected by the
activity we recommend that all system administrators check for the
signs of intrusion detailed in this advisory.

This advisory describes the activities that have been identified as
part of this particular incident.  This does not address the
possibility that systems may have been compromised due to other,
unrelated intrusion activity.

---------------------------------------------------------------------------

I.   Description

     The intruders gain initial access to a host by discovering a
     password for a user account on the system, exploiting a "+" in 
     the "/etc/hosts.equiv" file, or any ".rhosts" files on the
     system.  The intruder then connects to the system using rsh and
     attempts to become root on the compromised system.  An alias of
     "decode" may be used to gain root privileges.

II.  Impact
     
     Having gained root access on a system, the intruder may make
     unauthorized changes to system binaries that can capture account
     information for both local and remote systems.  In addition, the
     intruder adds "+ +" to any ".rhosts" files to which the intruder
     has access.

III. Solution 

     A. Check your systems for signs of intrusion due to this incident.

        1. Check the login, telnet, and uucpd binaries (for example,
           "/bin/login", "/usr/ucb/telnet", and "/usr/etc/in.uucpd" on
           Sun systems) against copies from distribution media.  Note that
           a check for creation or modification times and sizes is
           not sufficient to assure that the files have not been modified.
           The CERT/CC suggests that you compare the output of the
           "sum(1)" or "cmp(1)" command on both the distribution and
           installed versions of the binaries.

        2. If the check from (A.1) indicates that your binaries have been
           modified, check for the presence of a password log file.  Since
           the name of the logfile is often changed, the name of the file
           should be obtained using the "strings(1)" command on the Trojan
           login, uucpd, or telnet binary.  Examples of filenames used on
           other systems are:

                               "/usr/spool/. " (dot space)
                               "/var/spool/secretmail/.l"
                               "/var/spool/secretmail/.log"
                               "/var/spool/secretmail/.tty"
                               "/var/spool/secretmail/.lock"
                               "/usr/tmp/.log"
                               "/usr/spool/uucp/.sys"
                               "/usr/spool/uucppublic/.hushlogin"
               	           "/usr/uucp/.sys"
                               "/mnt2/lost+found/.tmp/.log"
                               "/usr/spool/mqueue/.AFG001"

           Verify that the contents of files found using the "strings(1)"
           command do not contain valid username/password combinations.  

        3. Check for the presence of "+" in the "/etc/hosts.equiv"
           file.  

           NOTE that Sun Microsystems installs the SunOS operating 
           system with a default "+" in the /etc/hosts.equiv
           file for easy network access.  This should be removed
           unless required in your operating environment and protected
           by a firewall network configuration.  Leaving the "+"
           intact will allow any non-root user on the Internet to
           login to the system without a password.

        4. Check the home directory for each entry in the "/etc/passwd"
           file for the presence of a ".rhosts" file containing
           "+ +" (plus space plus).

        5. Assure that your "/etc/fstab", "/etc/inetd.conf", and
           "/etc/exports" files have not been modified.

     B. Take the following steps to secure your systems.

        1. Save copies of the identified files to removable media and 
           remove any password log files as found in (A.2) above.

        2. Replace any modified binaries with copies from
           distribution media.

        3. Remove the "+" entry from the "/etc/hosts.equiv"
           file and the "+ +" (plus space plus) entry from any
           ".rhosts" files.  

        4. Change ownership of the "/etc" directory to userid "root"
           if it is owned by "bin" (as distributed by Sun).
           
        5. Change every password on the system and assure that the new 
           passwords are robust using a package such as Crack or Cops
           (available via anonymous ftp from cert.org).

        6. Inspect and restore any changes made to your "/etc/fstab", 
           "/etc/exports", or "/etc/inetd.conf" files.  If any
           modifications are found in these files, you will need to
           unmount file systems and restart daemons once the files
           have been restored.  Alternatively the system could be
           rebooted.
     
        7. Remove the "decode" alias from your global mail aliases
           file ("/etc/aliases" on Sun systems, "/usr/lib/aliases" on
           other UNIX systems).
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC or
your representative in FIRST (Forum of Incident Response and Security Teams).

Internet E-mail: cert@cert.org
Telephone: 412-268-7090 (24-hour hotline)
           CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous ftp
from cert.org (192.88.209.5).


****************************************************************************
*                                                                          *
*    The point of contact for MILNET security-related incidents is the     *
*    Security Coordination Center (SCC).                                   *
*                                                                          *
*               E-mail address: SCC@NIC.DDN.MIL                            *
*                                                                          *
*               Telephone: 1-(800)-365-3642                                *
*                                                                          *
*    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
*    Monday through Friday except on federal holidays.                     *
*                                                                          *
****************************************************************************
**************************************************************************
Security Bulletin 9219                  DISA Defense Communications System
July 22, 1992               Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

  The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
  Coordination Center) under DISA contract as a means of communicating
  information on network and host security exposures, fixes, and concerns
  to security and management personnel at DDN facilities.  Back issues may
  be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  using login="anonymous" and password="guest".  The bulletin pathname is
  scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  and "nn" is a bulletin number, e.g. scc/ddn-security-9219).
**************************************************************************

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important advisory was issued by the Computer       !
!     Emergency Response Team (CERT) and is being relayed unedited      !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center distribution system as a means of providing   !
!     DDN subscribers with useful security information.                 !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

===========================================================================
CA-92:15                        CERT Advisory
                                July 21, 1992
                    Multiple SunOS Vulnerabilities Patched

---------------------------------------------------------------------------

The CERT/CC (Computer Emergency Response Team/Coordination Center) has
received information concerning several vulnerabilities in the Sun
Microsystems, Inc. (Sun) operating system (SunOS).  These vulnerabilities 
affect all architectures and supported versions of SunOS including 4.1, 
4.1.1, and 4.1.2 on sun3, sun3x, sun4, sun4c, and sun4m.  The patches have 
been released as upgrades to three existing patch files.

Since application of these patches involves rebuilding your system kernel 
file (/vmunix), it is recommended that you apply all patches simultaneously.
Use the procedure described below to apply the patches and rebuild the kernel.

Sun has provided patches for these vulnerabilities as updates to
Patch IDs 100173, 100376, and 100567. They are available through your local
Sun Answer Centers worldwide as well as through anonymous ftp from the 
ftp.uu.net (137.39.1.9) system (in the /systems/sun/sun-dist directory).

Fix                     Patch ID       Filename            Checksum

NFS Jumbo               100173-08    100173-08.tar.Z      32716   562
Integer mul/div         100376-04    100376-04.tar.Z      12884   100 
ICMP redirects          100567-02    100567-02.tar.Z      23118    13

Please note that Sun Microsystems sometimes updates patch files.  If you 
find that the checksum is different, please contact Sun Microsystems or CERT 
for verification.

---------------------------------------------------------------------------

NFS jumbo patch upgrade, SunOS 4.1, 4.1.1, 4.1.2, all architectures

I.   Description

     The upgrade to the NFS Jumbo patch addresses a vulnerability that
     allows an intruder to become root using NFS.  This vulnerability
     affects all architectures and supported versions of SunOS.
     
II.  Impact

     A remote user may exploit this vulnerability to gain root access.

III. Solution 

     Extract the new files to be installed in the kernel.

     Install the patch files in /sys/`arch -k`/OBJ as described in the
     README file included in the patch file.  Be sure to make a backup
     of each file you are replacing before moving the patched file to the
     /sys/`arch -k`/OBJ directory.

     Config, make, and install the new kernel to include all patches
     described in this advisory, as appropriate to your system.  Reboot
     each host using the appropriate kernel.  Refer to the Systems and
     Network Administration manual for instructions on building and
     configuring a new custom kernel.


Integer mul/div patch upgrade, SunOS 4.1, 4.1.1, 4.1.2, SPARC architectures

I.   Description

     The integer mul/div patch upgrade addresses an additional problem with
     the integer multiplication emulation code on SPARC architectures. The
     current code allows an intruder to become root.  This vulnerability
     affects SPARC architectures (sun4, sun4c, and sun4m) for all supported
     versions of SunOS (4.1, 4.1.1, and 4.1.2).
     
II.  Impact

     A local user may exploit a bug in the emulation routines to gain
     root access or crash the system.

III. Solution 

     Extract the new files to be installed in the kernel.  Note that
     this patch applies only to SPARC architectures.

     Install the patch files in /sys/`arch -k`/OBJ as described in the
     README file included in the patch file.  Be sure to make a backup
     of each file you are replacing before moving the patched file to the
     /sys/`arch -k`/OBJ directory.

     As appropriate to your system, config, make, and install the new kernel
     to include all patches described in this advisory.  Reboot each host
     using the appropriate kernel.  Refer to the Systems and Network
     Administration manual for instructions on building and configuring a
     new custom kernel.


ICMP redirects patch upgrade, SunOS 4.1, 4.1.1, 4.1.2, all architectures

I.   Description

     The ICMP redirects patch addresses a denial of service vulnerability 
     with SunOS that allows an intruder to close existing network
     connections to and from a Sun system.  This vulnerability affects all
     Sun architectures and supported versions of SunOS.
     
II.  Impact

     A remote user may deny network services on a Sun system.

III. Solution

     Extract the new file to be installed in the kernel (the patch is
     the same for all supported versions of SunOS).

     Install the patch files in /sys/`arch -k`/OBJ as described in the
     README file included in the patch file.  Be sure to make a backup
     of each file you are replacing before moving the patched file to the
     /sys/`arch -k`/OBJ directory.
 
     As appropriate to your system, config, make, and install the new kernel
     to include all patches described in this advisory .  Reboot
     each host using the appropriate kernel.  Refer to the Systems and
     Network Administration manual for instructions on building and
     configuring a new custom kernel.

---------------------------------------------------------------------------
The CERT/CC wishes to thank Helen Rose of the EFF, Gordon Irlam of the
University of Adelaide, Wietse Venema of Eindhoven University, and Ken
Pon at Sun Microsystems, Inc for their assistance.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT/CC or
your representative in FIRST (Forum of Incident Response and Security Teams).

Internet E-mail: cert@cert.org
Telephone: 412-268-7090 (24-hour hotline)
           CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous ftp
from cert.org (192.88.209.5).


****************************************************************************
*                                                                          *
*    The point of contact for MILNET security-related incidents is the     *
*    Security Coordination Center (SCC).                                   *
*                                                                          *
*               E-mail address: SCC@NIC.DDN.MIL                            *
*                                                                          *
*                 Telephone: 1-(800)-365-3642                              *
*                                                                          *
*    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
*    Monday through Friday except on federal holidays.                     *
*                                                                          *
****************************************************************************
**************************************************************************
Security Bulletin 9221                  DISA Defense Communications System
August 14, 1992             Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

  The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
  Coordination Center) under DISA contract as a means of communicating
  information on network and host security exposures, fixes, and concerns
  to security and management personnel at DDN facilities.  Back issues may
  be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  using login="anonymous" and password="guest".  The bulletin pathname is
  scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  and "nn" is a bulletin number, e.g. scc/ddn-security-9221).
**************************************************************************

                         Virus Alert: "ALIENS 4"

On Saturday, August 8 1992, what is believed to be a new "polymorhpic" or
"adaptive" virus strain was detected on a Macintosh IIci running System 7
at the Space Environment Lab in Boulder, Colorado.

The NOAA/NIST staff working on the problem have been unable to identify this
particular strain, so have given it the name "Aliens 4" because:

    (1) It's fast

    (2) It mutates

    (3) It likes to travel

    (4) Every time you think you've eradicated it, it pops up somewhere else.


It is not known at this time whether the virus came in on an infected floppy
or via Internet or DECnet.  However, there is a strong suspicion that the virus
can travel via networks.


We also suspect that this virus is one of the new viral strains that can
"mutate" into different forms, making it extremely dangerous because it is
difficult (if not impossible) to trace and very difficult to eradicate.

The investigation continues, but this is what has been found out so far:

    (1) It appears to infect System 7 Mac's easier than System 6.07 systems.

    (2) It appears as seemingly random system malfunctions (disk drives can't
        read disks, printer problems, uncommon desktop displays).

    (3) It does NOT appear to destroy files.

    (4) Symantec (and others) seem capable of detecting it, but unable to
        eradicate it completely.

    (5) It was first reported by anti-viral software as the nVIR A strain,
        then the MBDF A strain, and so on.  For this reason, it has been
        identified as a polymorphic or adaptive filter.

    (6) The only 100% effective solution to date seems to be the "hard"
        re-formatting of infected disks.

The point-of-contact for information about the ALIENS 4 virus is:

     Mr. Dave Bouwer
     dbouwer@selvax.sel.bldrdoc.gov
     (303) 497-3899

If more concrete information on this virus becomes
available, interested parties will be notified.


******************************************************************************
**                                                                          **
**   The DDN Security Coordination Center (SCC) would like to thank         **
**   Mr. Dave Bouwer for bringing this to our attention.                    **
**                                                                          **
******************************************************************************


****************************************************************************
*                                                                          *
*    The point of contact for MILNET security-related incidents is the     *
*    Security Coordination Center (SCC).                                   *
*                                                                          *
*               E-mail address: SCC@NIC.DDN.MIL                            *
*                                                                          *
*               Telephone: 1-(800)-365-3642                                *
*                                                                          *
*    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
*    Monday through Friday except on federal holidays.                     *
*                                                                          *
****************************************************************************
**************************************************************************
Security Bulletin 9222                  DISA Defense Communications System
August 25, 1992             Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

  The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
  Coordination Center) under DISA contract as a means of communicating
  information on network and host security exposures, fixes, and concerns
  to security and management personnel at DDN facilities.  Back issues may
  be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  using login="anonymous" and password="guest".  The bulletin pathname is
  scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  and "nn" is a bulletin number, e.g. scc/ddn-security-9222).

**************************************************************************
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following message is being relayed unedited via the           !
!     Defense Information Systems Agency's Security Coordination        !
!     Center distribution system as a means of providing DDN            !
!     subscribers with useful security information.                     !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

                            "ALIENS 4": Epilogue
                                 Dave Bouwer
                                  23 Aug 92

On August 15, 1992, an alert for what was believed to be a new  
"polymorphic" or "adaptive" virus strain was posted.  This virus was  
detected on a Macintosh IIci running System 7 at the Space Environment  
Laboratory in Boulder, Colorado.  I was the researcher at NOAA/SEL that
originated the alert, and I assume full responsibility for it.

To make a long story short, "Aliens 4" is a ghost--that is, it was either  
a legitimate description or a peculiar combination of multiple  
viruses  and system software problems.  In any case, two weeks of 
work have  failed  to reproduce the original virus, and the alert needs 
to be canceled.

For interested readers, I'm describing the circumstances that led 
to the alert and giving some of my personal reflections.  I hope to be 
as honest as  possible in this description so that others in a similar 
situation can learn from my experience.  None of the views here 
represent those of NOAA or anyone else.

The Space Environment Lab (SEL) is an amalgam of talented physicists,
computer specialists, students, and administrative personnel.  We do
no classified work, but provide important near-real-time forecasts of the
solar-terrestrial environment in addition to performing general research
in solar-terrestrial physics.  A potential "hacker" has no need to raid
our systems:  We are delighted to provide data nearly free of charge!

The computer environment at SEL is a complex combination of real-time
systems, super-computer links, high-end workstations, personal computers,
and a strained ethernet network tying everything together. SEL's extremely
capable staff are always trying, like most shops, to catch up on a 
demanding  backlog of new systems, upgrades, bugs, programming, etc. 
We deal with an enormous amount of data: About 5 GB a day come through our
Services division alone.

I have been active in the computer sciences for nearly 20 years as a  
developer, systems manager, and high-end user.  While I am a long  
way from "guru" status, I have a long string of experiences and 
considerable education in government, university, and private industry. 
About 50% of my time is devoted to my  research in the time series analysis
of solar variability; the rest is spent in putting  together the latest
in systems for scientific research.

In other words, it was not without careful consideration or some  
expertise that I escalated the virus alert to a national level:  the 
consequences of not alerting others seemed VERY serious, and I was 
nearly certain of what I had observed.

Generally, at SEL, we have tended to worry little about computer 
security and have implemented only the basic measures, usually as 
an afterthought.  Our priority is to get the job done, and most users 
in the lab manage their own systems both by choice and necessity. 
However, in the last year the MS-DOS systems have seen two infections:
the infamous "Stoned" and "Michelangelo" viruses.  Our concern about data
security is  beginning to increase.  After all, we do work just down
the street from a major university with a large computer science department!

The nine Macintosh systems are all less than a year old, and there  
have seldom been any problems (least of all viruses). The "Lab Mac," 
which  was  available in a general computer lab area for visiting staff, 
students, etc., has been one of my responsibilities.  Since I much prefer
doing my papers and  memos on the Mac instead of on my desk-top DECstation,
I frequently used it and kept it working well (I have been using a Mac for
about 5 years altogether, with a long history of VAX/VMS systems and some
Unix).  About once a month, or whenever a peculiar problem would emerge, 
I would run various combinations of our older anti-viral programs over all
the files, and I had never found a problem.  I was over-confident that our
systems were unlikely to be seriously infected.

I discovered the virus on Saturday, August 8, 1992, when I noticed a  
MandelZot Fractal application on the Lab Mac.  Obviously, the neophyte
students were doing what every new computer science student seems to do
on a nice graphics system: making pictures for their dorm rooms!  Such
creative endeavors are not to be discouraged: they often generate enthusiasm
and lead to new ideas.  When I clicked on the application to see how they
were doing, the application alerted me to an infection (ALL applications
should do that!).

Not too worried and a little amused, I began to check it out.  The  
fractal application was last modified August 17, 1992, at 11:50 PM. 
(somebody was in very late!) Interferon informed me that a "Type 2"
error was found in the System, Finder, MandleZot, Photoshop, Canopener,
Mac Profiler,  Norton, System Sleuth, and Interferon (now that doesn't
exactly instill a secure feeling!).  I was the one running all the
applications, so I figured I had a VERY infected system.  Since it was
a Saturday, and I had a date, I put a notice on all the users' Macs
(I did not know whether the virus had propagated via the network), posted
a Lab-wide  bulletin, and physically disconnected the Ethernet connections
from all the Macs.  I shut down the Pathworks process running on our
Micro VAX/VMS server.

Sunday I came in to work on the problem (so much for my day of fly-fishing
my favorite river!). I ran Virus Rx 1.6, and it immediately became infected
(I can't recall all that it found).  Next, I tried Disinfectant 2.4. 
It reported what the Interferon run the day before had reported, identifying
the virus as an nVIR A strain. I decided to wait until Monday to talk to our
local NIST experts (we work in a large facility with an excellent networking
staff).  I began putting together a new Mac we had just received, planning
to use it as a "test" machine.  I also started planning how to campaign for
new Lab computer security measures:  the long-term implications were  
beginning to sink in!

I issued a stronger Lab-wide memo telling users they MUST back up their
files NOW.  I disabled all Macs and told users to see me before starting
their systems. As you can imagine, this directive was not received well
the next day.  In my overwhelming fear of lost data, I decided to err on
the side of caution. This was my first mistake: over-reacting and creating
an atmosphere of panic.

Monday, amidst countless user problems, I managed to sit down at the
infected machine with the local security guru.  He came armed with the
latest versions of SAM and Norton.  By then, there were dozens of reports
of printers not  working, system crashes, odd screens, and disk drives
not working.  At this point, I was becoming convinced that at least 3 Macs
were infected.  Only the System 6 Mac's seemed problem-free.  I suspected
that our local Ethernet network was carrying the virus somehow. This was
mistake number two: When users panic, every glitch that would normally be
ignored becomes a  symptom of the virus.  I mis-diagnosed the extent of the
problem on the basis of heresy, and not on my own direct experience.

Since one of my bosses -- the one who approves all my recommended  
purchases -- was out of town, I broke the rules and had the division 
secretary rush-order $1800 of SAM and Norton software.  Mistake 
number three: potential loss of data in the organization may not be 
grounds for overstepping one's authority.

First we ran SAM (version 2.8 or 2.9).  It reported the nVIR A strain as  
the other diagnostic software had on the previous day.  My NIST 
colleague asked if I had another infected system or disk, and I said I 
was sure I did.  Mistake number four: I should have made absolutely certain
I had copies of the suspected virus.  Other people will want to see any
reported virus.

We then told SAM to go ahead and eradicate the virus.  It said it had 
done so, without a problem.  We ran SAM again, and here was where all my
alarms went off:  On the second run, all the prior infected files and a
few new ones (the infected Versaterm Client application was the most ominous)
were infected with the MBDF A virus! 

We ran SAM again, telling it to fix the files. Again, it said it did so  
without any problems.  Since we were running from write-locked floppies,
the system had to re-boot.  When it came back up, my external LaCie drive
would not mount. The internal hard drive seemed to have no more problems. 
My NIST colleague could only tell me what I already knew: I had a  problem!

I consulted with another Mac expert, and he informed me about the new
adaptive or polymorphic viruses. Then an alert user gave me the new IEEE
Spectrum issue on data security (an excellent treatment in my opinion). 
I became convinced I had at least a 50% chance of having a polymorphic
virus, and that's when I notified CERT of the ALIENS 4 virus (I came up
at the last minute with the name: I felt I had to call it something!).
Mistake number five was in jumping to a conclusion too soon.

Now it's two weeks later.  Despite seriously overdue projects, I have  
worked entirely on:

   (1) Rebuilding the infected system after erasing the drives
       (implementing the new 7.01, Pathworks 1.1, and removing 
       all but the DECnet and FTP network extensions).

   (2) Trying to find the infected disk that started it all,
       or at least SOME copy of it.

   (3) Defending against management, user, and network criticisms.

   (4) Campaigning for new resources for new Lab-wide computer security
       measures.

So far I've only successfully completed (1), and I'm giving up on the 
other three tasks.  It's very hard to maintain political and technical  
clout after getting labeled as a "Chicken-Little."  I do know that a  
department in the University has Macs riddled with the nVIR A strain and a
copy of an X-rated script that MIGHT be used as a Trojan horse (I will be
forwarding copies of that virus and the script to Symantec, Apple, and CERT,
but I believe they will see nothing other than a simple nVIR A strain and
a script of poor taste.)  Other than the normal "glitches," there has been
no additional evidence of an infection.

To this day I believe the Lab had a new viral strain that posed a serious
risk.  However, I still ask myself whether I either: (a) saved the lab and
others from catastrophic data loss, or (b) thoroughly embarrassed the
Lab and myself.  I'm sure (b) is true, but I guess I'll never know about (a).
I still maintain that the highest priority, when data loss looms and
confusion and fear begin to overwhelm the beleaguered system manager,
is to protect the data.  Yet I should have been more careful in deciding
to escalate the alarm.

In conclusion, because I am unable to reproduce the virus, ALIENS 4 is
just a "ghost."  What we all have to ask ourselves is:  Is ALIENS 4 a  
ghost of "Christmas Future?"  If I did observe a polymorphic or adaptive
virus coming in on some innocuous Trojan horse, how could anyone else know
it?  And if the consequences of a false alarm are too severe, who would
risk their career by reporting a "potential threat"?  Finally, how are we
going to defend ourselves against this kind of mutating computer threat (if
it indeed becomes realized) in departments already straining their resources
to the limits?

I leave these questions to the readers of this confessional. I've got a 
very serious backlog of work to do.

	Sincerely,

	Dave Bouwer.


****************************************************************************
*                                                                          *
*    The point of contact for MILNET security-related incidents is the     *
*    Security Coordination Center (SCC).                                   *
*                                                                          *
*               E-mail address: SCC@NIC.DDN.MIL                            *
*                                                                          *
*               Telephone: 1-(800)-365-3642                                *
*                                                                          *
*    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
*    Monday through Friday except on federal holidays.                     *
*                                                                          *
****************************************************************************
**************************************************************************
Security Bulletin 9223                  DISA Defense Communications System
September 24, 1992          Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

  The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
  Coordination Center) under DISA contract as a means of communicating
  information on network and host security exposures, fixes, and concerns
  to security and management personnel at DDN facilities.  Back issues may
  be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  using login="anonymous" and password="guest".  The bulletin pathname is
  scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  and "nn" is a bulletin number, e.g. scc/ddn-security-9223).
**************************************************************************

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important advisory was issued by the Computer       !
!     Emergency Response Team (CERT) and is being relayed unedited      !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center distribution system as a means of             !
!     providing DDN subscribers with useful security information.       !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

CA-92:16                        CERT Advisory
                             September 22, 1992
                         VMS Monitor Vulnerability

---------------------------------------------------------------------------

The CERT Coordination Center has received information concerning a
potential vulnerability with Digital Equipment Corporation's VMS
Monitor.  This vulnerability is present in V5.0 through V5.4-2 but has
been corrected in V5.4-3 through V5.5-1.  The Software Security
Response Team at Digital has provided the following information
concerning this vulnerability.  

NOTE: Digital suggests that customers who are unable to upgrade their
systems implement the workaround described below.

For additional information, please contact your local Digital Equipment
Corporation customer service representative.


       Beginning of Text provided by Digital Equipment Corporation
==============================================================================
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 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:
-------------------------------------------------------------------------------
    Under certain conditions, unauthorized privileges may be expanded to
    authorized users of a system via the Monitor utility.   Should a system
    be compromised through unauthorized access, there is a risk of potential
    damage to a system environment.  This vulnerability will not permit
    unauthorized persons to acces the system, 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 preferably, 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 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 MONITORING 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
   $

   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.

   NOTE: The ID -SYSTEM- is an example; as necessary, substitute
         valid user ID's associated with accounts you wish to grant
         access to.

===========================================================================
	End of Text provided by Digital Equipment Corporation


---------------------------------------------------------------------------
CERT wishes to thank Teun Nijssen of CERT-NL (the SURFnet CERT, in the
Netherlands) for bringing this security vulnerability to our attention.
We would also like to thank Digital Equipment Corporation's Software Security 
Response Team for providing information on this vulnerability.  
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT or
your representative in FIRST (Forum of Incident Response and Security Teams).

Internet E-mail: cert@cert.org
Telephone: 412-268-7090 (24-hour hotline)
          CERT personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
          on call for emergencies during other hours.

CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous ftp
from cert.org (192.88.209.5).

****************************************************************************
*                                                                          *
*    The point of contact for MILNET security-related incidents is the     *
*    Security Coordination Center (SCC).                                   *
*                                                                          *
*               E-mail address: SCC@NIC.DDN.MIL                            *
*                                                                          *
*               Telephone: 1-(800)-365-3642                                *
*                                                                          *
*    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
*    Monday through Friday except on federal holidays.                     *
*                                                                          *
****************************************************************************

**************************************************************************
Security Bulletin 9225                  DISA Defense Communications System
October 7, 1992             Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

  The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
  Coordination Center) under DISA contract as a means of communicating
  information on network and host security exposures, fixes, and concerns
  to security and management personnel at DDN facilities.  Back issues may
  be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  using login="anonymous" and password="guest".  The bulletin pathname is
  scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  and "nn" is a bulletin number, e.g. scc/ddn-security-9225).

**************************************************************************

           TAC Access Control Policy Circular Announcement

    A circular describing TAC Access and related policies will soon
    be released in conjunction with the release of DDN Management 
    Bulletin #101, which describes MILNET TAC user validation and 
    registration. This circular will define the areas of respon-
    sibility for procuring TAC Access and make public the official 
    policies and procedures regarding the administration, processing,
    validation and distribution of MILNET TAC Access Cards.

    The "TAC Access Control Policy Circular" will apply to all
    Service and Agency host and gateway administrators who are 
    authorized to submit requests for TAC Cards. The circular will
    be provided to other addresses for general information and 
    guidance.

    The Circular will consist of seven parts each of which will 
    describe the various aspects of TAC Access in detail. Among 
    those topics discussed will be the following:

        * policies for authorization and administration
          of network access via a TAC,

        * procedures for ensuring network security and
          preventing unauthorized TAC Access,

        * proper procedures for using TAC Access Cards,

        * a description of the re-registration process and
          its function relative to TAC Card issuance,

        * updated policies and procedures related to
          quarterly Guest TAC Cards.

	In addition to the information outlined in this Circular,
	please refer to the following DDN Management Bulletins for
	further discussion of procedures and policies relating to
	TAC Usage and TAC Card issuance:

	   * DDN Management Bulletin #37, 16 Dec 87, DDN Node Site
	     Coordinator (NSC) and Host Administrator Duties

	   * DDN Management Bulletin #94, 16 Mar 92, MILNET/NIC
	     Re-registration Schedule and TAC Card Expiration

	   * DDN Management Bulletin #101, 24 Sep 92, MILNET TAC
	     User Validation and Registration

    All gateways,concentrators, or routers that are directly
    attached to the MILNET (i.e., those that have a 26 network 
    address) have designated administrators that are registered 
    with the NIC. These administrators have primary responsibility 
    for requesting/authorizing TAC Access Cards. The gateway admini-
    istrators have the option of delegating this authority to the host 
    administrators of systems that access MILNET via their gateways.
    These host administrators must also be registered with the NIC. 
    Users applying for TAC access cards must contact their local host 
    administrators or the NIC to determine the required signature 
    authority for their site.

    Hosts that are directly connected to MILNET (those that have a 
    network address of 26) also have designated administrators that 
    must be registered with the NIC. These host administrators have the 
    authority to request TAC access cards.  However, some MILNET hosts
    that are currently direct-connected are being disconnected and 
    moved behind gateways/concentrators. The administrators of such hosts
    must be delegated the authority to request TAC access cards by the
    administrator of the gateway that provides their connection to
    MILNET (in accordance with the Draft TAC Access Control Policy 
    Circular).

    This delegation of authority will allow administrators of hosts
    behind gateways/concentrators to register their users to their local
    hosts and to request TAC Access Cards for them. Users of hosts that
    have moved behind gateways must be re-registered so that they will 
    appear in the NIC database as associated with the correct host and
    gateway. Therefore, all administrators of hosts moving behind gateways
    MUST coordinate with the administrator of their gateway/concentrator
    and with the DDN NIC Registrar to arrange the re-registration of 
    their TAC users BEFORE the host on which they are currently registered
    is disconnected.

****************************************************************************
*                                                                          *
*    The point of contact for MILNET security-related incidents is the     *
*    Security Coordination Center (SCC).                                   *
*                                                                          *
*               E-mail address: SCC@NIC.DDN.MIL                            *
*                                                                          *
*               Telephone: 1-(800)-365-3642                                *
*                                                                          *
*    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
*    Monday through Friday except on federal holidays.                     *
*                                                                          *
****************************************************************************
**************************************************************************
Security Bulletin 9226                  DISA Defense Communications System
November 19, 1992           Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

  The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
  Coordination Center) under DISA contract as a means of communicating
  information on network and host security exposures, fixes, and concerns
  to security and management personnel at DDN facilities.  Back issues may
  be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  using login="anonymous" and password="guest".  The bulletin pathname is
  scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  and "nn" is a bulletin number, e.g. scc/ddn-security-9226).

**************************************************************************
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT) and is being relayed unedited      !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center distribution system as a means of providing   !
!     DDN subscribers with useful security information.                 !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

CA-92:18
                            CERT Advisory
                          November 17, 1992
                  Revised VMS Monitor Vulnerability 

---------------------------------------------------------------------------
				   
                *** THIS IS A REVISED CERT ADVISORY ***
*** IT CONTAINS NEW INFORMATION REGARDING AVAILABILITY OF IMAGE KITS ***
               *** SUPERSEDES CERT ADVISORY CA-92:16 ***


The CERT Coordination Center received information concerning a
potential vulnerability with Digital Equipment Corporation's VMS
Monitor. This vulnerability is present in V5.0 through V5.4-2 but has
been corrected in V5.4-3 through V5.5-1.  The Software Security 
Response Team at Digital has provided the following information
concerning this vulnerability.

The remedial image kit was not available at the time CERT distributed
the CA-92:16.VMS.monitor.vulnerability advisory (dated September 22,
1992).  At that time, Digital strongly suggested that customers either
upgrade to VMS V5.4-3 (preferably to V5.5-1) or implement the provided
workaround if unable to upgrade.

The following SSRT-200-1 addendum contains information about the
availability of new images to address the possible vulnerability with
VMS Monitor.

This last and final addendum includes new information about remedial
images for VMS V5.0 through V5.4-2.
 
Digital strongly suggests that those customers who were unable to
upgrade their systems (i.e., VMS V5.0 through V5.4-2) obtain and
install the remedial image kit on their system(s).

For additional information, please contact your normal Digital 
Services Support Organization.


 	   The information separated by the hash (#) line is
	 excerpted from the previously published CERT 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 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
     users to access a system, 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)

#############################################################################
	End of material excerpted from previously published CERT Advisory


          Beginning of Text Provided by Digital Equipment Corporation
=============================================================================
     21-OCT-1992 SSRT-0200-1 (ADDENDUM)
     21-AUG-1992 SSRT-0200
	
     SOURCE: 		Digital Equipment Corporation
     AUTHOR: 		Software Security Response Team - U.S.
                        Colorado Springs USA

	     PRODUCT: VMS MONITOR V5.0 through V5.4-2 

             PROBLEM: Potential Security Vulnerability in VMS Monitor Utility
            SOLUTION: A VMS V5.0 through V5.4-2 remedial kit is now available 
                      by contacting your normal Digital Services Support 
                      organization.     

            NOTE:     This problem has been corrected in VAX VMS V5.4-3
                      (released in October 1991).  
           __________________________________________________________________
           The kit may be identified as MONTOR$S01_05* or CSCPAT_1047 
           via DSIN , and DSNlink.
	   ------------------------------------------------------------------
	
     Copyright (c) Digital Equipment Corporation, 1992 All Rights Reserved.
     Published Rights Reserved Under The Copyright Laws Of The United States.

     -------------------------------------------------------------------------	
     ADVISORY ADDENDUM INFORMATION:
     -------------------------------------------------------------------------	

     In August 1992, an advisory and article were distributed describing a 
     potential security vulnerability discovered in the VMS Monitor utility and
     providing suggested workarounds to remove the vulnerability. The advisory
     was labeled SSRT-200 "Potential Security Vulnerability in VMS Monitor
     Utility."

     This advisory follows that advisory with information on the
     availability of a kit containing a new sys$share:spishr.exe for VMS
     V5.0-* through VMS V5.4-2 (which may be identified as MONTOR$S01_050
     through MONTOR$S01_054, respectively).  The kit is available from
     your Digital Services organization.  In the U.S., the kit is also
     identified as CSCPAT_1047 via DSIN and DSNlink.

Note:This potential vulnerability does not exist in VMS V5.4-3 and later
     versions of VMS.  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)

     If you cannot upgrade to a minimum of VMS V5.4-3 at this time,
     Digital strongly recommends that you install the available V5.0-* 
     through V5.4-2 kit on your system(s), available from your support 
     organization, to avoid any potential vulnerability. 

     You may obtain a kit for VMS V5.0 through V5.4-2 by contacting your normal
     Digital Services support organization (Customer Support Center, using 
     DSNlink or DSIN, or your local support office).  

     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.

===========================================================================
        End of Text provided by Digital Equipment Corporation

---------------------------------------------------------------------------
CERT wishes to thank Teun Nijssen of CERT-NL (the SURFnet CERT, in the
Netherlands) for bringing this security vulnerability to our attention.
We would also like to thank Digital Equipment Corporation's Software Security
Response Team for providing information on this vulnerability.
---------------------------------------------------------------------------

If you believe that your system has been compromised, contact CERT or
your representative in FIRST (Forum of Incident Response and Security Teams).

Internet E-mail: cert@cert.org
Telephone: 412-268-7090 (24-hour hotline)
           CERT personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

****************************************************************************
*                                                                          *
*    The point of contact for MILNET security-related incidents is the     *
*    Security Coordination Center (SCC).                                   *
*                                                                          *
*               E-mail address: SCC@NIC.DDN.MIL                            *
*                                                                          *
*               Telephone: 1-(800)-365-3642                                *
*                                                                          *
*    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
*    Monday through Friday except on federal holidays.                     *
*                                                                          *
****************************************************************************

**************************************************************************
Security Bulletin 9227                  DISA Defense Communications System
December 11, 1992           Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

  The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
  Coordination Center) under DISA contract as a means of communicating
  information on network and host security exposures, fixes, and concerns
  to security and management personnel at DDN facilities.  Back issues may
  be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  using login="anonymous" and password="guest".  The bulletin pathname is
  scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  and "nn" is a bulletin number, e.g. scc/ddn-security-9227).

**************************************************************************
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center  distribution  system  as a  means  of        !
!     providing  DDN subscribers with useful security information.      !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

CA-92:20                         CERT Advisory
                               December 10, 1992
                        Cisco Access List Vulnerability
-----------------------------------------------------------------------------

The CERT Coordination Center has received information concerning a
vulnerability with Cisco routers when access lists are utilized.  This
vulnerability is present in Cisco software releases 8.2, 8.3, 9.0 and 9.1.

Cisco Systems and CERT strongly recommend that sites using Cisco routers
for firewalls take immediate action to eliminate this vulnerability from
their networks.

This vulnerability is fixed in Cisco software releases 8.3 (update 5.10),
9.0 (update 2.5), 9.1 (update 1.1) and in all later releases.  Customers
who are using software release 8.2 and do not want to upgrade to a later
release should contact Cisco's Technical Assistance Center (TAC) at
800-553-2447 (Internet: tac@cisco.com) for more information.

The following interim releases are available via anonymous FTP from
ftp.cisco.com (131.108.1.111).

Note: this FTP server will not allow filenames to be listed or matched
with wildcards.  Also, you cannot request the file by its full pathname.
You must first cd to the desired directory (beta83_dir, beta90_dir, or
beta91_dir) and then request the desired file (gs3-bfx.83-5.10, etc.).

 Release (Update)  Filename                       Size       Checksum
     8.3 (5.10)    /beta83_dir/gs3-bfx.83-5.10    1234696    02465  1206
     9.0 (2.5)     /beta90_dir/gs3-bfx.90-2.5     1705364    47092  1666
     9.1 (1.1)     /beta91_dir/gs3-k.91-1.1       2005548    59407  1959

For those customers having a maintenance contract, these releases are also
available on Cisco's Customer Information On-Line (CIO) service.
Other customers may obtain these releases through Cisco's Technical
Assistance Center or by contacting their local Cisco distributor.

-----------------------------------------------------------------------------

I.   Description

     A vulnerability in Cisco access lists allows some packets that one
     would expect to be filtered by the access list to be erroneously routed 
     and vice-versa.  This vulnerability can allow unauthorized traffic
     to pass through the gateway and can block authorized traffic.

II.  Problem

     If a Cisco router is configured to use extended IP access lists for
     traffic filtering on an MCI, SCI, cBus or cBusII interface, and the IP
     route cache is enabled, and the "established" keyword is used in the
     access list, then the access list can be improperly evaluated.  This
     can permit packets that should be filtered and filter packets that
     should be permitted.

III. Workaround

     This vulnerability can be avoided by either rewriting the extended
     access list to eliminate the "established" keyword, or by configuring
     the interface to eliminate the IP route cache.  To disable the IP route
     cache, use the configuration command "no ip route-cache".

     Example for a serial interface:
        router>enable

        Password:
        router#configure terminal

        Enter configuration commands, one per line.
        Edit with DELETE, CTRL/W, and CTRL/U; end with CTRL/Z
        interface serial 0
        no ip route-cache
        ^Z
        router#write memory

IV.  Solution

     Obtain and install the appropriate interim release listed above.
     Sites that are not experienced with this installation process
     should contact the TAC center at 800-553-2447 for assistance.

---------------------------------------------------------------------------
The CERT Coordination Center wishes to thank Keith Reynolds of the
Santa Cruz Operation for his assistance in identifying this problem
and Cisco Systems for their assistance in providing technical information
for this advisory.
---------------------------------------------------------------------------
If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in FIRST (Forum of Incident
Response and Security Teams).

Internet E-mail: cert@cert.org
Telephone: 412-268-7090 (24-hour hotline)
           CERT personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
           on call during other hours for emergencies.

CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous FTP
from cert.org (192.88.209.5).


****************************************************************************
*                                                                          *
*    The point of contact for MILNET security-related incidents is the     *
*    Security Coordination Center (SCC).                                   *
*                                                                          *
*               E-mail address: SCC@NIC.DDN.MIL                            *
*                                                                          *
*               Telephone: 1-(800)-365-3642                                *
*                                                                          *
*    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
*    Monday through Friday except on federal holidays.                     *
*                                                                          *
****************************************************************************



**************************************************************************
Security Bulletin 9301                  DISA Defense Communications System
January 14, 1993            Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

  The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
  Coordination Center) under DISA contract as a means of communicating
  information on network and host security exposures, fixes, and concerns
  to security and management personnel at DDN facilities.  Back issues may
  be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  using login="anonymous" and password="guest".  The bulletin pathname is
  scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  and "nn" is a bulletin number, e.g. scc/ddn-security-9301).
**************************************************************************
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center  distribution  system  as a  means  of        !
!     providing  DDN subscribers with useful security information.      !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

=============================================================================
CA-93:01                         CERT Advisory
                               January 13, 1993
                Revised Hewlett-Packard NIS ypbind Vulnerability

-----------------------------------------------------------------------------

                   *** THIS IS A REVISED CERT ADVISORY ***
   *** IT CONTAINS NEW INFORMATION REGARDING AVAILABILITY OF IMAGE KITS ***
                  *** SUPERSEDES CERT ADVISORY CA-92:17 ***

The CERT Coordination Center has received information concerning a
vulnerability in the NIS ypbind module for the Hewlett-Packard (HP)
HP/UX Operating System for series 300, 700, and 800 computers. 

HP has provided revised patches for all of the HP/UX level 8 releases
(8.0, 8.02, 8.06, and 8.07).  This problem is fixed in HP/UX 9.0.
The following patches have been superseded:

              Patch ID        Replaced by Patch ID
              PHNE_1359       PHNE_1706
              PHNE_1360       PHNE_1707
              PHNE_1361       PHNE_1708

All HP NIS clients and servers running ypbind should obtain and 
install the patch appropriate for their machine's architecture
as described below.

-----------------------------------------------------------------------------

I.   Description

     A vulnerability in HP NIS allows unauthorized access to NIS data.

II.  Impact

     Root on a remote host running any vendor's implementation of NIS
     can gain root access on any local host running HP's NIS ypbind. 
     Local users of a host running HP's NIS ypbind can also gain root access.

III. Solution
        
     1) All HP NIS clients and servers running ypbind should obtain and 
        install the patch appropriate for their machine's architecture.

        These patches contain a version of ypbind that accepts ypset
        requests only from a superuser port on the local host.  This prevents
        a non-superuser program from sending rogue ypset requests to ypbind.
        The patches also include the mod from the superseded patches that 
        prevents a superuser on a remote system from issuing a ypset -h 
        command to the local system and binding the system to a rogue ypserver.

        These patches may be obtained from HP via FTP (this is NOT
        anonymous FTP) or the HP SupportLine.  To obtain HP security
        patches, you must first register with the HP SupportLine.
        The registration instructions are available via anonymous FTP at
        cert.org (192.88.209.5) in the file
	            "pub/vendors/hp/supportline_and_patch_retrieval".
        The new patch files are:

     Architecture Patch ID   Filename                               Checksum
     ------------ --------   --------                               --------
     Series 300   PHNE_1706  /hp-ux_patches/s300_400/8.X/PHNE_1706  38955 212
     Series 700   PHNE_1707  /hp-ux_patches/s700/8.X/PHNE_1707        815 311
     Series 800   PHNE_1708  /hp-ux_patches/s800/8.X/PHNE_1708      56971 299

     2) The instructions for installing the patch are provided in the
        PHNE_xxxx.text file (this file is created after the patch has
        been unpacked).

        The checksums listed above are for the patch archive files from HP.
        Once unpacked, each shell archive contains additional checksum 
        information in the file "patchfilename.text".  This checksum is
        applicable to the binary patch file "patchfilename.updt".


If you have any questions about obtaining or installing the patches,
contact the USA HP SupportLine at 415-691-3888, or your local HP
SupportLine number.  Please note that the telephone numbers in this
advisory are appropriate for the USA and Canada. 

-----------------------------------------------------------------------------
The CERT Coordination Center wishes to thank Brian Kelley of Ford Motor
Company for bringing this vulnerability to our attention.  We would also
like to thank Hewlett-Packard for their response to this problem. 
-----------------------------------------------------------------------------

If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in FIRST (Forum of Incident
Response and Security Teams).

Internet E-mail: cert@cert.org
Telephone: 412-268-7090 (24-hour hotline)
           CERT personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous FTP
from cert.org (192.88.209.5).


****************************************************************************
*                                                                          *
*    The point of contact for MILNET security-related incidents is the     *
*    Security Coordination Center (SCC).                                   *
*                                                                          *
*               E-mail address: SCC@NIC.DDN.MIL                            *
*                                                                          *
*               Telephone: 1-(800)-365-3642                                *
*                                                                          *
*    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
*    Monday through Friday except on federal holidays.                     *
*                                                                          *
****************************************************************************

**************************************************************************
Security Bulletin 9302                  DISA Defense Communications System
January 21, 1993            Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

  The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
  Coordination Center) under DISA contract as a means of communicating
  information on network and host security exposures, fixes, and concerns
  to security and management personnel at DDN facilities.  Back issues may
  be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  using login="anonymous" and password="guest".  The bulletin pathname is
  scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  and "nn" is a bulletin number, e.g. scc/ddn-security-9302).
**************************************************************************
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important advisory was issued by the Computer       !
!     Emergency Response Team (CERT) and is being relayed unedited      !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center distribution system as a means of             !
!     providing DDN subscribers with useful security information.       !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

CA-93:02                        CERT Advisory
                              January 20, 1993
                   NeXT NetInfo "_writers" Vulnerabilities

-----------------------------------------------------------------------------

The CERT Coordination Center has received information from NeXT Computer,
Inc. concerning a vulnerability in the distributed printing facility of NeXT
computers running all releases of NeXTSTEP software through NeXTSTEP Release
3.0.  For more information, please contact your authorized support center.
If you are an authorized support provider, please contact NeXT through your
normal channels.

-----------------------------------------------------------------------------

I.   Description

     The default NetInfo "_writers" properties are configured to allow
     users to install printers and FAX modems and to export them to the
     network without requiring assistance from the system administrator.
     They also allow a user to configure other parts of the system, such as
     monitor screens, without requiring help from the system administrator.
     Vulnerabilities exist in this facility that could allow users to gain
     unauthorized privileges on the system.


II.  Impact

     In the case of the "/printers" and the "/fax_modems" directories, the
     "_writers" property can permit users to obtain unauthorized root
     access to a system.

     In the "/localconfig/screens" directory, the "_writers" property can
     potentially permit a user to deny normal login access to other users.


III. Solution

     To close the vulnerabilities, remove the "_writers" properties from
     the "/printers", "/fax_modems", and "/localconfig/screens" directories
     in all NetInfo domains on the network, and from all immediate
     subdirectories of all "/printers", "/fax_modems", and
     "/localconfig/screens" directories.  The "_writers" properties may be
     removed using any one of the following three methods:

     A. As root, use the "niutil" command-line utility.  For example, to
        remove the "_writers" property from the "/printers" directory:

          # /usr/bin/niutil -destroyprop . /printers _writers


     B. Alternatively, use the NetInfoManager application: open the
        desired domain, open the appropriate directory, select the
        "_writers" property, choose the "Delete" command [Cmd-r] from
        the "Edit" menu, and save the directory.


     C. To assist system administrators in editing their NetInfo
        domains, a shell script, "writersfix", is available via
        anonymous FTP from next.com (129.18.1.2):

          Filename                                   Size   Checksum
          --------                                   ----   --------
          pub/Misc/Utilities/WritersFix.compressed   5515   53660 6

        After transferring this file using BINARY transfer type,
        double-click on the file.  A "WritersFix" directory will be
        created in your file system, containing the script
        ("writersfix") and some documentation ("WritersFix.rtf").


     Consider removing "_writers" from other NetInfo directories as well
     (for example, "/locations"), noting the following trade-off between
     ease-of-use and security.  By removing the "_writers" properties, the
     network and the computers on the network become more secure, but a
     system administrator's assistance is required where it previously was
     not required.

     Please refer to the NeXTSTEP Network and System Administration manual
     for additional information on "_writers".  Note that the
     subdirectories of the "/users" directory have "_writers_passwd" set to
     the user whose account is described by the directory.  This is
     essential if users are to be able to change their own passwords, and
     this does not compromise system security.

-----------------------------------------------------------------------------
The CERT Coordination Center wishes to thank Alan Marcum and Eric Larson of
NeXT Computer, Inc. for notifying us about the existence of these
vulnerabilities and for providing appropriate technical information.
-----------------------------------------------------------------------------

If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in FIRST (Forum of Incident
Response and Security Teams).

Internet E-mail: cert@cert.org
Telephone: 412-268-7090 (24-hour hotline)
           CERT personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous FTP
from cert.org (192.88.209.5).

****************************************************************************
*                                                                          *
*    The point of contact for MILNET security-related incidents is the     *
*    Security Coordination Center (SCC).                                   *
*                                                                          *
*               E-mail address: SCC@NIC.DDN.MIL                            *
*                                                                          *
*               Telephone: 1-(800)-365-3642                                *
*                                                                          *
*    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
*    Monday through Friday except on federal holidays.                     *
*                                                                          *
****************************************************************************

**************************************************************************
Security Bulletin 9303                  DISA Defense Communications System
January 22, 1993            Published by: DDN Security Coordination Center
                                      (SCC@NIC.DDN.MIL)   1-(800) 365-3642

                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN

  The DDN SECURITY BULLETIN is distributed by the DDN SCC (Security
  Coordination Center) under DISA contract as a means of communicating
  information on network and host security exposures, fixes, and concerns
  to security and management personnel at DDN facilities.  Back issues may
  be obtained via FTP (or Kermit) from NIC.DDN.MIL [192.112.36.5]
  using login="anonymous" and password="guest".  The bulletin pathname is
  scc/ddn-security-yynn (where "yy" is the year the bulletin is issued
  and "nn" is a bulletin number, e.g. scc/ddn-security-9303).
**************************************************************************
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
!                                                                       !
!     The following important  advisory was  issued by the Computer     !
!     Emergency Response Team (CERT)  and is being relayed unedited     !
!     via the Defense Information Systems Agency's Security             !
!     Coordination Center  distribution  system  as a  means  of        !
!     providing  DDN subscribers with useful security information.      !
!                                                                       !
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

CA-93:02a                       CERT Advisory
                              January 21, 1993
    REVISION NOTICE: New Patch for NeXT NetInfo "_writers" Vulnerabilities

-----------------------------------------------------------------------------

                 *** THIS IS A REVISED CERT ADVISORY ***
                   *** IT CONTAINS NEW INFORMATION ***

The CERT Coordination Center has received updated information from NeXT
Computer, Inc. concerning vulnerabilities in the distributed printing
facility of NeXT computers running all releases of NeXTSTEP software
through NeXTSTEP Release 3.0.  The online patch described in CERT
Advisory CA-93:02 has been replaced with a new patch.  The size and
checksum information in this Advisory have been updated to reflect
the new online patch.

For more information, please contact your authorized support center.  If you
are an authorized support provider, please contact NeXT through your normal
channels.

-----------------------------------------------------------------------------

I.   Description

     The default NetInfo "_writers" properties are configured to allow
     users to install printers and FAX modems and to export them to the
     network without requiring assistance from the system administrator.
     They also allow a user to configure other parts of the system, such as
     monitor screens, without requiring help from the system administrator.
     Vulnerabilities exist in this facility that could allow users to gain
     unauthorized privileges on the system.


II.  Impact

     In the case of the "/printers" and the "/fax_modems" directories, the
     "_writers" property can permit users to obtain unauthorized root
     access to a system.

     In the "/localconfig/screens" directory, the "_writers" property can
     potentially permit a user to deny normal login access to other users.


III. Solution

     To close the vulnerabilities, remove the "_writers" properties from
     the "/printers", "/fax_modems", and "/localconfig/screens" directories
     in all NetInfo domains on the network, and from all immediate
     subdirectories of all "/printers", "/fax_modems", and
     "/localconfig/screens" directories.  The "_writers" properties may be
     removed using any one of the following three methods:

     A. As root, use the "niutil" command-line utility.  For example, to
        remove the "_writers" property from the "/printers" directory:

          # /usr/bin/niutil -destroyprop . /printers _writers


     B. Alternatively, use the NetInfoManager application: open the
        desired domain, open the appropriate directory, select the
        "_writers" property, choose the "Delete" command [Cmd-r] from
        the "Edit" menu, and save the directory.


     C. To assist system administrators in editing their NetInfo
        domains, a shell script, "writersfix", is available via
        anonymous FTP from next.com (129.18.1.2):

          Filename                                   Size   Checksum
          --------                                   ----   --------
          pub/Misc/Utilities/WritersFix.compressed   5600   25625  6

        After transferring this file using BINARY transfer type,
        double-click on the file.  A "WritersFix" directory will be
        created in your file system, containing the script
        ("writersfix") and some documentation ("WritersFix.rtf").


     Consider removing "_writers" from other NetInfo directories as well
     (for example, "/locations"), noting the following trade-off between
     ease-of-use and security.  By removing the "_writers" properties, the
     network and the computers on the network become more secure, but a
     system administrator's assistance is required where it previously was
     not required.

     Please refer to the NeXTSTEP Network and System Administration manual
     for additional information on "_writers".  Note that the
     subdirectories of the "/users" directory have "_writers_passwd" set to
     the user whose account is described by the directory.  This is
     essential if users are to be able to change their own passwords, and
     this does not compromise system security.

-----------------------------------------------------------------------------
The CERT Coordination Center wishes to thank Alan Marcum and Eric Larson of
NeXT Computer, Inc. for notifying us about the existence of these
vulnerabilities and for providing appropriate technical information.
-----------------------------------------------------------------------------

If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in FIRST (Forum of Incident
Response and Security Teams).

Internet E-mail: cert@cert.org
Telephone: 412-268-7090 (24-hour hotline)
           CERT personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.

CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890

Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous FTP
from cert.org (192.88.209.5).

****************************************************************************
*                                                                          *
*    The point of contact for MILNET security-related incidents is the     *
*    Security Coordination Center (SCC).                                   *
*                                                                          *
*               E-mail address: SCC@NIC.DDN.MIL                            *
*                                                                          *
*               Telephone: 1-(800)-365-3642                                *
*                                                                          *
*    NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST,   *
*    Monday through Friday except on federal holidays.                     *
*                                                                          *
****************************************************************************
