-------- From academic-firewalls-owner@net.tamu.edu Thu May 11 21:00:27 1995 X-Sender: swift@tamiya.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 11 May 1995 18:53:27 -0700 From: uncl@llnl.gov (Frank Swift at Home) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: CIAC Bulletin F-23 1 of 2 Date: Thu, 11 May 1995 13:14:19 -0700 Errors-To: listmanager@cheetah.llnl.gov Reply-To: fisher@bill.llnl.gov Originator: ciac-bulletin@cheetah.llnl.gov Sender: ciac-bulletin@cheetah.llnl.gov Precedence: bulk From: fisher@bill.llnl.gov (John M. Fisher) To: uncl@llnl.gov Subject: CIAC Bulletin F-23 X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas ________________________________________________________ The U.S. Department of Energy Computer Incident Advisory Capability ___ __ __ _ ___ / | /_\ / \___ __|__ / \ \___ __________________________________________________________ INFORMATION BULLETIN Protecting IBM AIX Systems Against SATAN May 11, 1995 1100 PDT Number F-23 _____________________________________________________________________ PROBLEM: SATAN, a tool for scanning Unix systems was released on April 5. The tools identifies exploitable vulnerabilities, most of which can be patched. PLATFORM: This bulletins focuses on SATAN's impact on IBM AIX Systems. DAMAGE: Anyone running SATAN can gain vulnerability information that can be exploited with other tools to gain privileged access. SOLUTION: Update all IBM AIX systems with the patches identified below. AVAILABILITY: All patches are available now. _____________________________________________________________________ VULNERABILITY When SATAN was released via the Internet on April 5, it ASSESSMENT: became available to anyone, including system administrators and security specialists who protect corporate systems. It is also available to others who could use it to gain information about unpatched system vulnerabilities and then exploit these vulnerabilities with other tools to gain unauthorized access. _____________________________________________________________________ CRITICAL Information for patching IBM AIX Vulnerabilities CIAC has obtained information from IBM describing the specific patches for the vulnerabilities SATAN will scan for. Specific patch details are provided below. [BEGINNING OF IBM AIX BULLETIN] .......................................................................... Preparing your AIX System for SATAN AIX Security Response Team security@austin.ibm.com .......................................................................... I. Purpose of this document II. AIX vulnerabilities probed by SATAN 1. NFS export to unprivileged programs 2. NFS export via portmapper 3. Unrestricted NFS export 4. NIS password file access 5. rexd access 6. Sendmail vulnerabilities 7. TFTP file access 8. Remote shell access 9. Unrestricted X server access 10. Writable FTP home directory 11. wu-ftpd vulnerability III. More information on AIX security IV. More information on internet security topics V. CERT advisory on SATAN .......................................................................... I. Purpose of this document .......................................................................... Everyone is becoming increasingly aware of computer security issues. No one wants to lose valuable information to unwanted intruders. The SATAN tool was developed to help system administrators secure all computers on their networks. The danger exists that this tool could be used for unlawful purposes. We want to help AIX users secure their systems so SATAN will not cause any problems. This document is intended to help AIX users understand each of the vulnerabilities probed by SATAN and learn what they can do to secure their systems in each of these areas. Many books and articles have been written on computer security configuration issues and we will refer you to these articles when appropriate. .......................................................................... II. AIX vulnerabilities probed by SATAN .......................................................................... .......................................................................... 1. NFS export to unprivileged programs .......................................................................... If the nfs mount daemon, rpc.mountd, is started with the -n flag it allows mount requests to come from non-privileged ports. This is used to allow some older versions of NFS to perform mounts. It should not be used. The AIX default is to not use the -n flag. For additional security use the nfso utility to turn on kernel port checking. The command would be: nfso -o nfs_portmon=1 (in AIX version 3 ) nfso -o portcheck=1 (in AIX version 4 ) The default in AIX is to NOT do kernel portchecking. .......................................................................... 2. NFS export via portmapper .......................................................................... Access to filesystems via portmapper is disabled by default in recent versions of AIX. To make sure you have a later version of portmapper that fixes this problem, check to make sure your machine has the fix for APAR IX32328. That fix has been included in PTFS U419992 U419994 U419995. Use the following aix cmd to determine if you have applied these ptfs: $ lslpp -al U419992 U419994 U419995 .......................................................................... 3. Unrestricted NFS export .......................................................................... Entering a directory or filesystem in the /etc/export list without specifying an access list allows any host who's IP address can be resolved to mount the directory. This is not secure. The access list should be specified when exporting filesystem objects. Exports specifying root access or read/write access also are inherently lower security and should be implemented with caution. .......................................................................... 4. NIS password file access .......................................................................... The ability to view encrypted passwords when NIS is being used and the ability to exploit the information can be curtailed and to some extent prevented in a number of ways. A) use a /var/yp/securenets file to restrict the NIS services to trusted networks. (see the notes on securenets below). B) Make the NIS domain name hard to guess and non-obvious. Employee turnover or other security concerns may require domain renaming. (use the chypdom command or smit chypdom to change domain names and move the /var/yp/ directory to the new name) C) Require users to use non-trivial passwords. Use of the /var/yp/securenets file: The implementation of ypserv and ypxfrd that utilize the securenets file was shipped in response to APAR ix32328 Some PTF's that contain that fix are: U419992 U419994 and U419995. Use the following aix cmd to determine if you have applied these ptfs: $ lslpp -al U419992 U419994 U419995 Both the "ypserv" and "ypxfrd" use a /var/yp/securenets file and, if present, only responds to IP addresses in the range given. This file is only read when the daemons (both ypserv & ypxfrd) start. To get a change in /var/yp/securenets to take effect, one must kill and restart the daemons. The format of the file is one or more lines of: netmask netaddr e.g. 255.255.0.0 128.30.0.0 255.255.255.0 128.311.10.0 In the 2nd example, the netmask is 255.255.255.0 and the network address is 128.311.10.0 . This setup will only allow the ypserv to respond to those IP addresses which are within the subnet 128.311.10 range. An additional NIS security note is that allowing ypset to reset ypbind binding lowers security. ypbind daemons shipped in the fix for APAR IX43595 (in PTF U431006) disallow ypset's as their default behavior and this is strongly recommended. Use the following aix cmd to determine if you have applied this ptf: $ lslpp -al U431006 .......................................................................... 5. rexd access .......................................................................... The rexd server allows users to execute commands on remote servers in an environment similar to that of the local system. No validation of identity or access permission is performed. This behavior leads many people to believe that the use of rexd is a security vulnerability. There are currently no known defects in the rpc.rexd command which adversely affect the security of the system. rpc.rexd is contained in the bosnet.nfs.obj.client subsystem. The most recent PTF for that subsystem as of the writing of this document is U436781. Use the following aix cmd to determine if you have applied this ptf: $ lslpp -al U436781 The lack of authentication of the identity of the invoker may present a security exposure in an untrustworthy environment. You should weigh the risks of a security exposure against the functionality provided when you consider enabling this service. The problems with rexd are inherent in the design of the server and cannot be corrected easily. The security problems can be limited by careful use of NFS exports on the client system and by disabling rexd on the server. IBM issued CA-92:05 on March 5, 1992 describing a problem with the initial configuration of rexd on AIX 3.1 and AIX 3.2 systems. APAR IX21353 was opened to correct this problem. The problem corrected by this APAR no longer exists in AIX 3.2.5 or AIX 4.1. In AIX 3.2.5 and 4.1 rexd is disabled by default when shipped. .......................................................................... 6. Sendmail vulnerabilities .......................................................................... All AIX versions of /usr/sbin/sendmail are vulnerable to some of the attacks described in CA-95:05. The official APARs resolving ALL known AIX sendmail vulnerabilities are IX49257 (version 3.2) and IX49604 (version 4.1). AIX users should obtain the emergency patch from Internet ftp site software.watson.ibm.com. The file is located in /pub/aix/sendmail/sendmail.tar.Z in compressed tar format. Please follow the installation instructions in the sendmail.readme file located in this same directory. Currently, AIX versions 3.2 and 4.1 are based on sendmail version 5.64. Although this is an old version of sendmail, all known sendmail security bugs are fixed by the emergency patch mentioned previously. If you permit automatic mail forwarding or programs that accept mail messages, please be sure there is no way for these programs to create a shell or send commands. This type of configuration can create a security hole that could be exploited by an unfriendly user. .......................................................................... 7. TFTP file access .......................................................................... The tftpd server allows users to retrieve files without requiring an account on the remote server. Tftpd is commonly used by diskless systems and X-stations as well. Tftp does not require the use of a user name or password and therefore may grant access to system data when the identity of the requestor has not been established. This may allow unknown users to acquire restricted data or to modify user files. There are currently no known defects in tftpd which adversely affect the security of the system. The tftpd command is contained in the bosnet.tcpip.obj.client subsystem. The most recent PTF for that subsystem as of the writing of this document is U435114. The lack of any authentication or identification of the requestor should be considered when configuring tftpd. The tftp service may be restricted using the /etc/tftpaccess.ctl file. This file is documented in InfoExplorer under the tftpd command. This function was added to AIX v3.1 by APAR IX22628 and is available in the 2014 level PTF. Tftp should be configured in /etc/inetd.conf to run as the user "nobody". The following line is an example of how to do this. tftp dgram udp wait nobody /etc/tftpd tftpd -n THIS EXAMPLE WILL ALLOW REMOTE USERS TO WRITE FILES ON THE LOCAL SYSTEM. If you have no requirement for granting write permission to remote users you should consider removing the "-n" flag from the command line given above. The user "nobody" should own no files or directories on the system. The only files or directories which the user "nobody" should be able to read are those with read or write (and execute for directories) permission to "other". Refer to the chmod command in InfoExplorer for details on how to manage file and directory permissions. By properly restricting access to "other", you will effectively limit the files and directories which tftpd may access and modify. IBM released CERT advisory CA:91-19 on October 17, 1991 for the tftpd daemon. The vulnerability described in that advisory is corrected in all releases of AIX v3.2 and AIX v4. .......................................................................... 8. Remote shell access .......................................................................... The rsh and rlogin commands are used to establish sessions on remote servers. Both commands operate in a similar manner from an access perspective. The file /etc/hosts.equiv or a .rhosts file in the user's home directory may be consulted to determine if access is granted. When access is not automatically granted for the rlogin command the remote user Frank Swift L-321 (Sent from Home) Unclassified Computer Security Coordinator Lawrence Livermore National Laboratory (LLNL) 7000 East Avenue L-321 Livermore CA 94550-9516 Voice: (510) 422-1463 FAX: (510) 423-0913 -------- From academic-firewalls-owner@net.tamu.edu Thu May 11 21:14:27 1995 Date: Thu, 11 May 95 22:11:22 EDT From: Moira West-Brown Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: E-Mail response expectation. [This is an automated reply.] Your message has been received, however I am out of the office between Tuesday 9th May and Friday May 12th. During that time I may only have limited access e-mail. If your message was regarding CERT business and if it was not sent (or cc'd) to "cert@cert.org", your message will go unaddressed until I return. Please resend any CERT-related e-mail to cert@cert.org so that CERT staff can review it and follow up if appropriate. Regards Moira Moira J. West-Brown Manager, Incident Handling CERT Coordination Center | Telephone: +1-412-268-7090 24-hour hotline Software Engineering Institute | CERT Coordination Center personnel answer Carnegie Mellon University | business days 08:30-17:00 EST/EDT Pittsburgh, PA 15213-3890 | (GMT-5)/(GMT-4), on call for emergencies U.S.A. | during other hours. Internet E-mail: cert@cert.org | Fax: +1-412-268-6989 -------- From academic-firewalls-owner@net.tamu.edu Thu May 11 21:20:35 1995 Content-Length: 545 Date: Thu, 11 May 1995 19:15:32 +0800 From: airnote@airnote.net (AirNote Gateway) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: Re: E-Mail response expectation. The AirNote Gateway has sent your message to the pager with PIN 1146673. Your mail message was received at Thu May 11 1995, 07:14:40 PM PDT. The message sent was: Moira West-Brown|E-Mail response expectation.|[This is an automated reply.] Your message has been received, however I am out of the office between Tuesday 9th May and Friday May 12th. During th|908 - ---- Thank you for using the AirNote Gateway from Notable Technologies, Inc. (For more information about AirNote, call 1-800-732-9900 or send e-mail to info@airnote.net) -------- From academic-firewalls-owner@net.tamu.edu Thu May 11 22:12:34 1995 X-Sender: swift@tamiya.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 11 May 1995 18:54:32 -0700 From: uncl@llnl.gov (Frank Swift at Home) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: CIAC Bulletin F-23 2 of 2 Date: Thu, 11 May 1995 13:14:19 -0700 Errors-To: listmanager@cheetah.llnl.gov Reply-To: fisher@bill.llnl.gov Originator: ciac-bulletin@cheetah.llnl.gov Sender: ciac-bulletin@cheetah.llnl.gov Precedence: bulk From: fisher@bill.llnl.gov (John M. Fisher) To: uncl@llnl.gov Subject: CIAC Bulletin F-23 X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas is prompted for a password. The rshd server has had one security related defect. APAR IX45182 corrected a defect in which the "-l" option (used to control operation of the server) did not work properly. This APAR was first delivered in PTF U432655. This PTF should be applied to any system which has been configured according to the instructions given below. This problem does not exist on any release of AIX v4. The rlogind server has had one significant security related defect. APARs IX44254 and IX44367 corrected a defect in which any network user was able to gain access to the remote system as any user. These APARs were first delivered in PTFs U431620 and U431622 respectively. Both of these PTFs or their superceding PTFs should be installed on all systems. This problem does not exist on any release of AIX v4. Two significant enhancements have been made to the rshd server. APAR IX45701 added a facility for restricting use of rshd and rexecd on a user by user basis. This feature may be useful for critical system accounts which might be subject to attack via a network connection. This APAR was first delivered in PTF U434068. APAR IX48235 added additional auditing capability. This feature may be useful when connecting to unsecure networks or when you are interested in monitoring rshd usage. A USER_Login audit event will be created for each rshd invocation. This may be used in conjunction with the TCPIP_access event to determine local user and remote hostname for each rshd and rexecd. As of the writing of this document this APAR has not been packaged into a PTF. Both rshd and rlogind are subject to security violations related to use of the /etc/hosts.equiv and $HOME/.rhosts files. This exposure can be removed by adding the "-l" flag to the rshd and rlogind command lines in /etc/inetd.conf. The following two lines are an example of how you might do this. shell stream tcp nowait root /etc/rshd rshd -l login stream tcp nowait root /etc/rlogind rlogind -l If you do not wish to grant remote network access to your system, you may disable this facility entirely with lines similar to the following. #shell stream tcp nowait root /etc/rshd rshd #login stream tcp nowait root /etc/rlogind rlogind Please refer to InfoExplorer for additional information on configuring the /etc/inetd.conf file and the inetd daemon. Should you choose to enable rshd and/or rlogind, the use of the /etc/hosts.equiv and $HOME/.rhosts files creates a dependency on the information in those files and the information which the servers use being accurate. Errors in either file or spoofing of host addresses or names are common causes of security exposures. When the network is not secure or trustworthy, consider disabling these services for some or all users or enabling the auditing subsystem to track possible attacks. You may also wish to consider use of a firewall or some other form of packet filter to restrict access to trustworthy hosts or networks. InfoExplorer describes the proper configuration of the /etc/hosts.equiv file. As a general rule, grant access to specific users and specific hosts. You should monitor the existence of .rhosts files and insure that users are educated about their proper use. The telnet service may be more appropriate in an unsecured network environment as it does not support the pre-authentication of users. CERT advisory CA-94:09 was released on May 23, 1994 describing the security exposure in the rlogin service. Use the following aix cmd to determine if you have applied one of these ptfs: $ lslpp -al U43xxxx .......................................................................... 9. Unrestricted X server access .......................................................................... In 1993 CERT issued advisory CA-93:17 which documented a xterm vulnerability in X11R5 and earlier versions of X11. This problem was resolved by the following apars: aixterm X11r4 : ix34738 - resolved by U417488 and U419246 aixterm X11r5 : ix40275 - resolved by ptf U425631 xterm X11r4 : ix40279 - resolved by ptf U425255 and U425228 xterm X11r5 : resolved by U493250 (3.2.5 Gold) Use the following aix cmd to determine if you have applied these ptfs: $ lslpp -al U4xxxxx If you are using AIX 3.2, please make sure you have all these ptfs applied to avoid potential security problems. These fixes are shipped as part of the GOLD version of AIX 4.1. Because of X11's design, the client/server can be accessed by any other host on the network. If you are on the Internet, your display can be accessed by any machine in the world. X11 security issues for AIX are similar to the X11 security problems facing other X11 vendors. It is difficult to make X completely secure. However, there are access control mechanisms which can be put in place to help make your environment more secure. You should never use the "xhost +" cmd because this will enable any remote user to read/write screen information. Please remove all "xhost +" cmds from any file or program on your system. A useful tool for limiting X access, please see the /usr/bin/xauth The best source of information on securing X is in : O'Reilly & Associates,Inc. "X Window System Adminstrator's Guide". Specifically chapter 4 which goes into detail about X security. The discussion in this chapter applies to the AIX environment. In additon, the Common Desktop Enviroment (CDE) interface available on AIX 4.1 uses XDMCP protocol discussed in this chapter. .......................................................................... 10. Writable FTP home directory .......................................................................... In 1992, CERT issued advisory CA-92:09 about an AIX Anonymous FTP Vulnerability. This problem was resolved by apar ix23944, which was included in the GOLD release of AIX 3.2. Thus, AIX 3.2 and 4.1 systems are not vulnerable to this problem. The original problem was discovered on AIX 3.1. If you are running AIX 3.1, please update to the latest release of 3.1, which resolves this problem. The following information can be very helpful: - - The ftpd man page has explicit instructions for securely configuring your anonymous FTP user and subtree. - - The /usr/lpp/samples/tcpip/anon.ftp file can be used to securely set up your anonymous account. (/usr/samples/tcpip/anon.ftp in AIX 4.1) - - The CERT tip found at ftp://info.cert.org/tech_tips/anonymous_ftp contains applicable information. .......................................................................... 11. wu-ftpd vulnerability .......................................................................... This problem only affects users running the wuarchive-ftpd. If you do not have this modified version of ftpd, then you are not vulnerable to this specific attack. If you are running the wuarchive-ftpd, and your version is dated prior to April 8, 1993, please take corrective action or remove this daemon. You can obtain more information about this service via anonymous ftp from wuarchive.wustl.edu (128.252.135.4). This service is NOT distributed with AIX. .......................................................................... III. More information on AIX security .......................................................................... We publish an AIX security newsletter that is updated whenever we have security information that affects AIX users. To subscribe to the newsletter: mail -s "subscribe security" aixserv@austin.ibm.com < /dev/null If you have comments or questions about AIX security, or you would like to notify us of a potential problem, please send mail to security@austin.ibm.com. To order an APAR from IBM in the U.S. call 1-800-237-5511. APARs may be obtained outside the U.S. by contacting a local IBM representative. [End of IBM AIX Bulletin] CIAC recently released CIAC NOTES 07 article (April 5, 1995) that is devoted to SATAN. The article was based on beta-releases of SATAN and is applicable to the current version 1.0 release of SATAN. There were no major operational changes between the latest beta release and the current version 1.0 public release. By configuring a system correctly, installing all the latest patches, and monitoring system usage, most of SATAN's techniques can be countered, or at a minimum detected. Unfortunately, complete protection from SATAN is difficult. Most of the vulnerabilities it looks for are easily addressable, but some do not yet have satisfactory solutions. CIAC has recently written a program to defend against SATAN and other similar tools. The program, called Courtney, monitors the connections to the ports probed by SATAN. When an attack by SATAN takes place, the offending host will be reported. CIAC has also make available the current release of SATAN SATAN is made up of HyperText Markup Language (HTML) documents, C code, and Perl scripts which generate HTML code dynamically. It requires an HTML viewer (Mosaic, Netscape, or Lynx), a C compiler, and PERL version 5. The user simply interacts with a WWW client, entering necessary data into forms. The control panel for SATAN provides four hypertext options: Target Selection, Reporting & Data Analysis, Documentation, and Configuration & Administration. Refer to CIAC Notes 7 for an indepth look at SATAN. ________________________________________________________________________________ CIAC wishes to thank Randy S. Greenberg of IBM for their response to this problem. ________________________________________________________________________________ CIAC is the computer security incident response team for the U.S. Department of Energy. Services are available free of charge to DOE and DOE contractors. For emergencies and off-hour assistance, DOE and DOE contractor sites can contact CIAC 24-hours a day via an integrated voicemail and SKYPAGE number. To use this service, dial 1-510-422-8193 or 1-800-759-7243 (SKYPAGE). The primary SKYPAGE PIN number, 8550070 is for the CIAC duty person. A second PIN, 8550074 is for the CIAC Project Leader. CIAC's FAX number is 510-423-8002, and the STU-III number is 510- 423-2604. Send E-mail to ciac@llnl.gov. Previous CIAC notices, anti-virus software, and other information are available on the CIAC Bulletin Board and the CIAC Anonymous FTP server. The CIAC Bulletin Board is accessed at 1200 or 2400 baud at 510-423-4753 and 9600 baud at 510-423-3331. The CIAC Anonymous FTP server is available on the Internet at ciac.llnl.gov (IP address 128.115.19.53). CIAC has several self-subscribing mailing lists for electronic publications: CIAC- BULLETIN, CIAC-NOTES , SPI-ANNOUNCE, and SPI-NOTES.To subscribe (add yourself) to one of our mailing lists, send requests of the following form to ciac- listproc@llnl.gov: subscribe list-name LastName, FirstName PhoneNumber For additional information or assistance, please contact CIAC: Voice: 510-422-8193 FAX: 510-423-8002 STU-III: 510-423-2604 E-mail: ciac@llnl.gov ATTENTION!! CIAC now has a web server at http://ciac.llnl.gov. 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. CIAC BULLETINS ISSUED IN FY95 (Previous bulletins available from CIAC) (F-01) SGI IRIX serial_ports Vulnerability (F-02) Summary of HP Security Bulletins (F-03) Restricted Distribution (F-04) Security Vulnerabilities in DECnet/OSI for OpenVMS (F-05) SCO Unix at, login, prwarn, sadc, and pt_chmod Patches Available (F-06) Novell UnixWare sadc, urestore, and suid_exec Vulnerabilities (F-07) New and Revised HP Bulletins (F-08) Internet Address Spoofing and Hijacked Session Attacks (F-09) Unix /bin/mail Vulnerabilities (F-10) HP-UX Remote Watch (F-11) Unix NCSA httpd Vulnerability (F-12) Kerberos Telnet Encryption Vulnerability (F-13) Unix sendmail vulnerabilities (F-14) HP-UX Malicious Code Sequences (F-15) HP-UX "at" and "cron" vulnerabilities (F-16) SGI IRIX Desktop Permissions Tool Vulnerability (F-17) Limited Distribution (F-18) MPE/iX Vulnerabilities (F-19) Protecting HP-UX Systems Against SATAN (F-20) Security Administrator Tool for Analyzing Networks (SATAN) (F-21) Protecting SUN OS Systems Against SATAN (F-22) SATAN Password Disclosure CIAC NOTES ISSUED IN FY1995 (Previous Notes available from CIAC) 04c December 8, 1994 05d January 11, 1995 06 March 22, 1995 07 March 29, 1995 08 April 4, 1995 09 April 24, 1995 Frank Swift L-321 (Sent from Home) Unclassified Computer Security Coordinator Lawrence Livermore National Laboratory (LLNL) 7000 East Avenue L-321 Livermore CA 94550-9516 Voice: (510) 422-1463 FAX: (510) 423-0913 -------- From academic-firewalls-owner@net.tamu.edu Fri May 12 18:01:10 1995 X-Sender: swift@tamiya.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 May 1995 15:56:23 -0700 From: uncl@llnl.gov (Frank Swift (510-422-1463)) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: CIAC Bulletin F-24: Protecting SGI IRIX Systems Against SATAN Date: Fri, 12 May 1995 10:12:21 -0700 Reply-To: dwsmith@cheetah.llnl.gov Originator: ciac-bulletin@cheetah.llnl.gov Sender: ciac-bulletin@cheetah.llnl.gov Precedence: bulk From: David Smith To: uncl@llnl.gov Subject: CIAC Bulletin F-24: Protecting SGI IRIX Systems Against SATAN - -----BEGIN PGP SIGNED MESSAGE----- __________________________________________________________ The U.S. Department of Energy Computer Incident Advisory Capability ___ __ __ _ ___ / | /_\ / \___ __|__ / \ \___ __________________________________________________________ INFORMATION BULLETIN Protecting SGI IRIX Systems Against SATAN May 11, 1995 1300 PDT Number F-24 _______________________________________________________________________________ PROBLEM: SATAN, a tool for scanning Unix systems was released on April 5. The tools identifies exploitable vulnerabilities, most of which can be patched. PLATFORM: This bulletin focuses on SATAN's impact on SGI IRIX Systems. DAMAGE: Anyone running SATAN can gain vulnerability information that can be exploited with other tools to gain privileged access. SOLUTION: Update all SGI IRIX systems with the patches identified below. AVAILABILITY: All patches are available now. _______________________________________________________________________________ VULNERABILITY When SATAN was released via the Internet on April 5, it ASSESSMENT: became available to anyone, including system administrators and security specialists who protect corporate systems. It is also available to others who could use it to gain information about unpatched system vulnerabilities and then exploit these vulnerabilities with other tools to gain unauthorized access. _______________________________________________________________________________ CRITICAL Information for patching SGI IRIX Vulnerabilities CIAC has obtained information from SGI describing the specific patches for the vulnerabilities SATAN will scan for. Specific patch details are provided below. [BEGINNING OF SGI IRIX BULLETIN] - - -----BEGIN PGP SIGNED MESSAGE----- ________________________________________________________________________________ Silicon Graphics Inc. Security Advisory Title: Release of SANTA/SATAN tool and SGI specifics Title: CERT CA-95:06 Security Administrator Tool for Analyzing Networks Number: 19950401-01-I Date: April 5, 1995 ________________________________________________________________________________ Silicon Graphics provides this information freely to the SGI community for its consideration, interpretation and implementation. Silicon Graphics recommends that this information be acted upon as soon as possible. Silicon Graphics will not be liable for any consequential damages arising from the use of, or failure to use or use properly, any of the instructions or information in this Security Advisory. ________________________________________________________________________________ The Silicon Graphics Incorporated Engineering and Customer Support Divisions have investigated the SATAN program and have completed this document to assist and inform ALL SGI customers in regards to SATAN issues. - - - -------------------- - - - -- What is SATAN? -- - - - -------------------- The Security Analysis Network Tool for Administrators/Security Administrator Tool for Analyzing Networks, also known as SANTA/SATAN, is a graphical administrator's tool that can remotely probe and analyze potential security issues on a wide variety of computer platforms. SATAN is scheduled to be released on April 5, 1995 at 14:00 GMT. Using the SATAN program, probes can be performed at several levels of increasing concentration, from light to heavy. The target of the probes can be on either a specific host, group of hosts or a network of hosts. At the conclusion of any probe, a complete report of potential security problems is provided. Each problem is briefly described, along with pointers to known patches and/or work-arounds. As part of the probe activity, SATAN also gathers general network information, including overall network topology, running network services, and types of hardware and software being used. Of particular note is the "exploratory mode" of SATAN. When probing in "exploratory mode," SATAN will probe hosts that have not been explicitly specified. These unspecified hosts are selected based on security problems found on initially specified hosts. This could result in SATAN probing not only targeted hosts, but also hosts outside your administrative domain and could be perceived as an attack. Be aware that unauthorized access to computer systems may expose you to potential civil liabilities and criminal penalties. The design of the SATAN provides for flexible extensibility via perl scripts. It is expected that many future extensions will be made available publically and privately for probing and/or exploiting security vulnerabilities. At this time, the initial version of SATAN does not actively exploit the vulnerabilities it finds. Please note that SGI does not provide, support or assist with the use of SATAN. However, SGI is very interested in investigating all potential IRIX security vulnerabilities discovered, whether by SATAN or other means. - - - -------------------------------------- - - - -- Where can the SATAN program and -- - - - -- SATAN documentation be obtained? -- - - - -------------------------------------- ***** Please note that SGI does not provide, support or assist with the use of SATAN. ***** SATAN information and documentation is available via WWW browser with: ftp://ftp.win.tue.nl/pub/security/satan_doc.tar.Z http://ciac.llnl.gov/ciac/ToolsUnixNetSec.html#Satan Or via anonymous ftp site : ftp.win.tue.nl in the directory: /pub/security/satan_doc.tar.Z Further documents are also available through a mail server provided by one of the SATAN authors. Send mail to: majordomo@wzv.win.tue.nl and put in one or any combination of following lines in the body (not the Subject:) of the mail: get satan mirror-sites get satan release-plan get satan description get satan admin-guide-to-cracking.101 It should be noted that the last document, admin-guide-to-cracking.101, contains "Improving the Security of Your Site by Breaking Into It," a 1993 paper in which the SATAN authors give their rationale for creating the program SATAN. - - - ---------------------------------------------------- - - - -- SATAN Vulnerabilities Probes and SGI Specifics -- - - - ---------------------------------------------------- In any environment, customers themselves must assess the work requirements and security vulnerabilities of their systems in order to take actions appropriate to the level of exposure noted in these assessments and all security issues. A system directly accessible from the Internet, i.e. not protected by firewalls, is significantly more vulnerable than a system in a collaborative environment protected from outside access. There is specific advice on a number of security related topics in the "Advanced Site and Server Administration Guide," particularly in Chapters 12 and 16, and in the IRIX on-line manual pages for the programs being examined by SATAN. In the details provided below, specific IRIX release specifics are mentioned when possible. When no specific release is indicated, the information applies to all IRIX releases. A. Writable ~ftp home directory The manual page for ftpd(1m) is recommended as the primary reference source for anonymous ftp service information. It must be noted that, although the manual page for ftpd(1m) in its description of how to setup an anonymous ftp service recommends that the ~ftp directory be owned by ftp and be mode 555, sites directly connected to the Internet should change the ownership of this directory to bin to preclude an external user modifying the permissions on the home directory. Additionally, care must be taken to follow the directions in the ftpd(1m) manual pages in setting up an anonymous ftp account. Anonymous ftp accounts are intrinsically vulnerable to misuse, so care and constant monitoring are critical. B. Unprivileged NFS access Although the mount daemon (mountd(1m)) permits access from unprivileged ports, this should be enabled only when specifically required, e.g. when access from a non-standard system is needed. Systems directly exposed to the Internet should not export any file systems and should disable mountd by editing /etc/inetd.conf (/usr/etc/inetd.conf for IRIX 4.x) as according to the manual page, mountd(1M). C. Unrestricted NFS export As shipped from the factory, IRIX does not export any file systems for remote NFS access. When it is required to export a file system, if possible, restricting NFS access to specific hosts and users might be considered. These restrictions can be established by editing /etc/exports in accordance with the the manual pages, exportfs(1M) and exports(4). D. NIS password file access NIS can be very useful in collaborative environments, but it is extremely vulnerable to a variety of threats. In sites where sensitive information must be protected, and where such activities as password- cracking or NIS server-spoofing cannot be prevented through administrative controls, NIS should not be used for passwords. Such sites could consider the use of shadow passwords on vulnerable systems to reduce the possibility of password-cracking. Systems directly exposed to the Internet should not use NIS and should not expose NIS servers behind the firewall. E. Portmap forwarding Systems directly exposed to the Internet should reduce the remotely invocable services supported to a level necessary to provide the required services. Generally, such a system should not be providing RPC services via portmap or rpcbind to the outside world, as these services were designed for collaborative environments, and do not have strong security protections. At those sites, where organizational needs require that these systems support RPC services, portmapper restrictions should be considered. Restrictions such as - - - -a mask,match which restricts access to specified networks, and -v which logs accesses from unprivileged ports are useful. These arguments are defined in the /etc/config/portmap.options file as outlined in the manual page, portmap(1M). F. tftp file access As shipped from the factory, tftp is secured with the -s option. However, the Installation guide and other installation documents will frequently have this turned off to accomplish a specific task. The manual page for tftpd and inetd, tftpd(1M) and inetd(1M), are to be referred to for ensuring the correct use of the -s option. The factory default is tftp dgram udp wait guest /usr/etc/tftpd tftpd -s \ /usr/local/boot /usr/etc/boot G. Remote shell (rsh) access As stated above, systems that are directly accessible (no firewall) to the Internet should restrict the remotely invocable services on that system to the absolute minimum necessary to perform the required function(s). As shipped from the factory, the IRIX operating system environment permits a fairly wide range of services through inetd(1M). Sites should reduce the available services by editing /etc/inetd.conf per the manual pages and refreshing inetd with the new configuration via "killall -HUP inetd". To remove a service, either comment the service out with a "#" character as the first character of the line, or remove the service line entirely from the file. Services left accessible can be configured to improve security by using certain options. Below, some options to consider are listed, but the manual pages should be referred to for completeness. rlogind use '-l' to disable validation using .rhosts files fingerd use '-l' to log all connections use '-S' to suppress information about login status, home directory, and shell use '-f msg-file' to make it just display that file rshd use 'a' to verify that all incoming remote host names and addresses match use '-l' to disable validation using .rhosts files use '-L' to log all access attempts to syslog For standard logins, it is prudent to enhance security with several options as described in the manual pages for login, login(1). login set MANDPASS=YES set SYSLOG=ALL set LOCKOUT=5 H. Vulnerability in rexd configuration The Remote Execution daemon, rexd, is an example of a service that is inappropriate on systems directly exposed to the Internet. The rexd daemon assumes a collaborative environment in making access control decisions. As such, the rexd program should be disabled by editing /etc/inetd.conf (on 5.x, 6.x) or /usr/etc/inetd.con (on 4.x) file as described above and in the manual pages, rexd(1M). The line below illustrates a disabled rexd program. #rexd/1 stream rpc/tcp wait root /usr/etc/rpc.rexd rexd I. Sendmail vulnerabilities SGI Security Advisory 19950201-02 addresses sendmail vulnerabilities recently reported in CERT 95:05. The advisory provides patch information on obtaining patch 332 that provides a 8.6.10 sendmail program. By connecting to the SMTP port, SATAN attempts to determine the version of sendmail running and determine secureness. SATAN's assessment may be incorrect even when the patch is installed. See the "SGI Patch Information" section below for further information on obtaining patches. J. Unrestricted X server access As factory shipped, IRIX fosters a cooperative X work environment between workstations by permitting remote systems to access the local X server. In less friendly environments, this can be considered a vulnerability. If this THE WORLD IS NOT INTERESTED IN THE STORMS YOU ENCOUNTERED, BUT WHETHER YOU BROUGHT IN THE SHIP . \ | / | 0 0 | Frank Swift L-321 (510)-422-1463 ~^~ LLNL 7000 East Avenue ( fax) 423-0913 \O/ Livermore CA 94550-9516_____________uncl@llnl.gov________+ Unclassified Computer Security Lawrence Livermore National Lab Observing and Reacting to "the Net of a Million Lies" -------- From academic-firewalls-owner@net.tamu.edu Fri May 12 18:01:47 1995 X-Sender: swift@tamiya.llnl.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 May 1995 15:57:04 -0700 From: uncl@llnl.gov (Frank Swift (510-422-1463)) Reply-To: academic-firewalls@net.tamu.edu To: academic-firewalls@net.tamu.edu Subject: CIAC Bulletin F-24: Protecting SGI IRIX Systems Against SATAN Date: Fri, 12 May 1995 10:12:21 -0700 Reply-To: dwsmith@cheetah.llnl.gov Originator: ciac-bulletin@cheetah.llnl.gov Sender: ciac-bulletin@cheetah.llnl.gov Precedence: bulk From: David Smith To: uncl@llnl.gov Subject: CIAC Bulletin F-24: Protecting SGI IRIX Systems Against SATAN is an issue for a given site or system, some issues may be be addressed with the following steps and configuration, which are documented in the manual pages, xhost(1), xmd(1), Xsgi(1), and xauth(1). Additionally, it is highly recommended to read the "X Window System System Administrator's Guide", O'Reilly Vol. 8. from O'Reilly & Associates, ISBN 0-937175-83-8. 1) Become root. % /bin/su - Password: # 2) Edit the file /usr/lib/X11/xdm/Xservers and add the line below. Normally there is only 1 line, but for TKO, be sure this is added for each Xserver. add option '-shmnumclients 0' 3) Save file. 4) Edit the /usr/lib/X11/xdm/xdm-config and make the following change. DisplayManager*authorize: off to DisplayManager*authorize: on 5) Save the file. 6) Edit the file /usr/lib/X11/xdm/Xsession.dt (or Xsession if not using the IndigoMagic desktop) and make the following change. # Gives anyone on any host access to this display /usr/bin/X11/xhost + to # restrict access to this host /usr/bin/X11/xhost - 7) Save the file. 8) Remove any 'xhost +' from the files /usr/lib/X11/xdm/Xsession* 9) Remove any 'xhost +' from users private .xsession files 10) Remove any /etc/X0.hosts or /etc/X.hosts files. 11) Ensure the proper permissions and ownership on the following important X configuration files. Use the chown and chmod commands to adjust accordingly. Permissions owner group file -r--r--r-- root sys /usr/lib/X11/xdm/Xservers -rwxr-xr-x root sys /usr/lib/X11/xdm/Xlogin -rwxr-xr-x root sys /usr/lib/X11/xdm/Xreset -rwxr-xr-x root sys /usr/lib/X11/xdm/Xstartup -rwxr-xr-x root sys /usr/lib/X11/xdm/Xstartup-remote -r--r--r-- root sys /usr/lib/X11/xdm/xdm-config -rwxr-xr-x root sys /usr/bin/X11/X lrwxr-xr-x root sys /X11/Xsgi -rwxr-xr-x root sys /usr/bin/X11/xdm -rwxr-xr-x root sys /usr/bin/X11/xauth -rwxr-xr-x root sys /usr/bin/X11/xhost 12) Restart the graphics system. # /usr/gfx/stopgfx; /usr/gfx/startgfx & K. NTP vulnerabilities Silicon Graphics Incorporated does not provide or support NTP. - - - --------------------------- - - - -- SGI Patch Information -- - - - --------------------------- When an IRIX security vulnerability is found, SGI will investigate the vulnerability and may generate a patch. Patches generated specially for security-related issues are freely available to all requesting customers. IRIX 4.x patches come as tar-bundled binaries and documentation that must be manually installed. Installation instructions are provided with the tar-bundle. For IRIX 5.1 and 5.1.x there are no security patches available. Upgrading to 5.2 or 5.3 is suggested. Patches provided for IRIX 5.2, 5.3 and 6.x are inst images and require a patch aware /usr/sbin/inst program. The stock IRIX 5.2 /usr/sbin/inst program is not patch-aware and must be updated. Patch 84 provides a patch aware inst program for IRIX 5.2. Security patches can be found on SGI anonymous ftp servers: ftp.sgi.com:~ftp/patches or sgigate.sgi.com:~ftp/patches *NOTE*: If a particular file is not found on one, please check the other site. For each security patch a file containing chksum and PGP information for that patch has been generated by the SGI Customer Security Coordinator. The SGI Security Coordinator Public key can be found at: ftp.sgi.com:~ftp/security/agent99.pgp.key.asc or sgigate.sgi.com:~ftp/security/agent99.pgp.key.asc For key fingerprint verification of the above, call +1-415-390-2965. - - - ----------------------------- - - - -- SGI Security Advisories -- - - - ----------------------------- SGI reports security vulnerabilities to the SGI community via Silicon Graphics Incorporated Security Advisories. This document is one such document. An archive of these documents can be found on SGI anonymous ftp servers: ftp.sgi.com:~ftp/security or sgigate.sgi.com:~ftp/security *NOTE*: If a particular file is not found on one, please check the other site. All Security Advisories are PGP digitally signed by the SGI Customer Security Coordinator. The SGI Security Coordinator Public key can be found at: ftp.sgi.com:~ftp/security/agent99.pgp.key.asc or sgigate.sgi.com:~ftp/security/agent99.pgp.key.asc For key fingerprint verification of the above, call +1-415-390-2965. - - - -------------------------- - - - -- Other security tools -- - - - -------------------------- The following tools are publicly available via ftp and could potentially improve a site's security. They are documented here for information only and are not provided, endorsed or supported by SGI. COPS and ISS are programs that check for vulnerabilities and configuration weaknesses. CERT advisory CA-93:14 and CA-93:14.README contain information about ISS. COPS is available from: ftp://info.cert.org:/pub/tools/cops/* ISS is available from: ftp://ftp.uu.net:/usenet/comp.sources.misc/volume39/iss The TCP wrappers system can provide access control and flexible logging for most network services. With proper configuration and use, potential network attacks can be prevent and/or detected. TCP wrappers is available from: ftp://info.cert.org:/pub/tools/tcp_wrappers/* The Swatch log file monitor identifies patterns in log file entries and attempts to associate entries with specific actions. Swatch software is available from: ftp://ee.stanford.edu:/pub/sources/swatch.tar.Z The Rscan program by Nate Sammons checks for many common IRIX-specific security bugs and problems. Rscan is available from: ftp://ftp.vis.colostate.edu/pub/rscan The Courtney package monitors the network and identifies the source machines of potential SATAN probes/attacks. Using a second package, tcpdump, Courtney counts the number of new services requests a machine originates within a certain time period. To Courtney, excessive service requests from a particular machine could indicate it as a potential SATAN probe/attacking host. Courtney software is available from: ftp://ciac.llnl.gov/pub/ciac/sectools/unix/courtney.tar.Z tcpdump software is available from: ftp://ftp.ee.lbl.gov/tcpdump-3.0.tar.Z *Note: the Courtney program requires a correction in order to run on IRIX. The file print-arp.c uses ETHERTYPE_ID which is undefined in IRIX. In places where it is referenced, it needs to be changed to look like: if ((pro != ETHERTYPE_IP #ifdef ETHERTYPE_TRAIL && pro != ETHERTYPE_TRAIL #endif - - - ----------------------------------- - - - -- Reporting SGI Vulnerabilities -- - - - -- Further Information/Contacts -- - - - ----------------------------------- For obtaining security information, patches or assistance, please contact your SGI support provider. If there are questions about this document, email can be sent to: cse-security-alert@csd.sgi.com For reporting *NEW* SGI security issues, email can be sent to: security-alert@sgi.com Please use these aliases wisely. Excessive unnecessary traffic can hinder problem assistance. Do not include the aliases in CC: lists without prudent consideration. - - -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBL4QdobQ4cFApAP75AQFXJgP/Yyv0UhzvAGesgc8tT2aZY3kjyLwlFT8t 6aYjviEDOsm/aMzUKffkqxzcM+yE7kXslk+0Qvw4jCGZjiMzE0h6mYONacRo5xjU QqLILtbi0j96UIxqT6L0T/FCVoPsHxV/kLW/iVId8HZ9NuZX50MbRaQ2uPwH9Rwd xJG+KHbrTVI= =lAHY - - -----END PGP SIGNATURE----- [END OF SGI IRIX BULLETIN] CIAC recently released CIAC NOTES 07 article (April 5, 1995) that is devoted to SATAN. The article was based on beta-releases of SATAN and is applicable to the current version 1.0 release of SATAN. There were no major operational changes between the latest beta release and the current version 1.0 public release. By configuring a system correctly, installing all the latest patches, and monitoring system usage, most of SATAN's techniques can be countered, or at a minimum detected. Unfortunately, complete protection from SATAN is difficult. Most of the vulnerabilities it looks for are easily addressable, but some do not yet have satisfactory solutions. CIAC has recently written a program to defend against SATAN and other similar tools. The program, called Courtney, monitors the connections to the ports probed by SATAN. When an attack by SATAN takes place, the offending host will be reported. CIAC has also make available the current release of SATAN SATAN is made up of HyperText Markup Language (HTML) documents, C code, and Perl scripts which generate HTML code dynamically. It requires an HTML viewer (Mosaic, Netscape, or Lynx), a C compiler, and PERL version 5. The user simply interacts with a WWW client, entering necessary data into forms. The control panel for SATAN provides four hypertext options: Target Selection, Reporting & Data Analysis, Documentation, and Configuration & Administration. Refer to CIAC Notes 7 for an indepth look at SATAN. ________________________________________________________________________________ ________________________________________________________________________________ CIAC is the computer security incident response team for the U.S. Department of Energy. Services are available free of charge to DOE and DOE contractors. For emergencies and off-hour assistance, DOE and DOE contractor sites can contact CIAC 24-hours a day via an integrated voicemail and SKYPAGE number. To use this service, dial 1-510-422-8193 or 1-800-759-7243 (SKYPAGE). The primary SKYPAGE PIN number, 8550070 is for the CIAC duty person. A second PIN, 8550074 is for the CIAC Project Leader. CIAC's FAX number is 510-423-8002, and the STU-III number is 510- 423-2604. Send E-mail to ciac@llnl.gov. Previous CIAC notices, anti-virus software, and other information are available on the CIAC Bulletin Board and the CIAC Anonymous FTP server. The CIAC Bulletin Board is accessed at 1200 or 2400 baud at 510-423-4753 and 9600 baud at 510-423-3331. The CIAC Anonymous FTP server is available on the Internet at ciac.llnl.gov (IP address 128.115.19.53). CIAC has several self-subscribing mailing lists for electronic publications: CIAC- BULLETIN, CIAC-NOTES , SPI-ANNOUNCE, and SPI-NOTES.To subscribe (add yourself) to one of our mailing lists, send requests of the following form to ciac- listproc@llnl.gov: subscribe list-name LastName, FirstName PhoneNumber For additional information or assistance, please contact CIAC: Voice: 510-422-8193 FAX: 510-423-8002 STU-III: 510-423-2604 E-mail: ciac@llnl.gov ATTENTION!! CIAC now has a web server at http://ciac.llnl.gov. 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. CIAC BULLETINS ISSUED IN FY95 (Previous bulletins available from CIAC) (F-01) SGI IRIX serial_ports Vulnerability (F-02) Summary of HP Security Bulletins (F-03) Restricted Distribution (F-04) Security Vulnerabilities in DECnet/OSI for OpenVMS (F-05) SCO Unix at, login, prwarn, sadc, and pt_chmod Patches Available (F-06) Novell UnixWare sadc, urestore, and suid_exec Vulnerabilities (F-07) New and Revised HP Bulletins (F-08) Internet Address Spoofing and Hijacked Session Attacks (F-09) Unix /bin/mail Vulnerabilities (F-10) HP-UX Remote Watch (F-11) Unix NCSA httpd Vulnerability (F-12) Kerberos Telnet Encryption Vulnerability (F-13) Unix sendmail vulnerabilities (F-14) HP-UX Malicious Code Sequences (F-15) HP-UX "at" and "cron" vulnerabilities (F-16) SGI IRIX Desktop Permissions Tool Vulnerability (F-17) Limited Distribution (F-18) MPE/iX Vulnerabilities (F-19) Protecting HP-UX Systems Against SATAN (F-20) Security Administrator Tool for Analyzing Networks (SATAN) (F-21) Protecting SUN OS Systems Against SATAN (F-22) SATAN Password Disclosure (F-23) Protecting IBM AIX Systems Against SATAN CIAC NOTES ISSUED IN FY1995 (Previous Notes available from CIAC) 04c December 8, 1994 05d January 11, 1995 06 March 22, 1995 07 March 29, 1995 08 April 4, 1995 09 April 24, 1995 - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBL7J3HbnzJzdsy3QZAQHxRgQApv74yRgnZ7Jv4rPlW6aF8yypn2BGIdDR ImJ8F2DmUmu8H1ujTFI4JYnv3lYgxAot9hFzg77U5LNnrcrAEWfs6/dAFHUdIZDk TXeX/QDuVkbfz/RAs6xkupPGGBIRSiK69Lv4rsvEu5aEbNDNC/27qUKEGiWjyytD mkAc3bYpb3w= =PIpB - -----END PGP SIGNATURE----- THE WORLD IS NOT INTERESTED IN THE STORMS YOU ENCOUNTERED, BUT WHETHER YOU BROUGHT IN THE SHIP . \ | / | 0 0 | Frank Swift L-321 (510)-422-1463 ~^~ LLNL 7000 East Avenue ( fax) 423-0913 \O/ Livermore CA 94550-9516_____________uncl@llnl.gov________+ Unclassified Computer Security Lawrence Livermore National Lab Observing and Reacting to "the Net of a Million Lies"