************************************************************************** Security Bulletin 9523 DISA Defense Communications System May 31, 1995 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-9428). ************************************************************************** + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ! ! ! The following important advisory was issued by the Automated ! ! Systems Security Incident Support Team (ASSIST) 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. ! ! ! + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Automated Systems Security Incident Support Team _____ ___ ___ _____ ___ _____ | / /\ / \ / \ | / \ | | / Integritas / \ \___ \___ | \___ | | < et /____\ \ \ | \ | | \ Celeritas / \ \___/ \___/ __|__ \___/ | |_____\ <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bulletin 95-20 Release date: May 20, 1995 08:21 AM EDT (GMT -4) SUBJECT: Protecting SGI IRIX Systems Against the Security Administrator Tool for analyzing Networks (SATAN). SUMMARY: Included within this bulletin is information issued by Silicon Graphics Inc. (SGI) describing the specific patches for the vulnerabilities SATAN will scan for. For additional information on SATAN, see ASSIST 95-11 (SATAN Network Vulnerability Analyzer), ASSIST 95-12 (SATAN Vulnerability), and ASSIST 95-16 (SATAN Vulnerability: Password Disclosure). BACKGROUND: SATAN is an automated tool released on the Internet in April 95 which will scan IP networks for exploitable vulnerabilities. IMPACT: Information about unpatched system vulnerabilities collected by SATAN can be used with other tools to gain unauthorized access to networked systems. RECOMMENDED SOLUTIONS: Read the information issued by SGI attached below and update all SGI IRIX systems with the appropriate patches. NOTE: The following text is from an SGI Security Advisory that has had non-critical sections edited out for the sake of brevity. Silicon Graphics Inc. Security Advisory Title: Release of SANTA/SATAN tool and SGI specifics Title: CERT CA-95:06 [ASSIST 95-11] 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. - - - ---------------------------------------------------- - - - -- 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 [ASSIST 95-07]. 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 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. - - - ----------------------------------- - - - -- 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. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ASSIST is an element of the Defense Information Systems Agency (DISA), Center for Information Systems Security (CISS), that provides service to the entire DoD community. Constituents of the DoD with questions about ASSIST or computer security security issues, can contact ASSIST using one of the methods listed below. Non-DoD organizations/institutions, contact the Forum of Incident Response and Security Teams (FIRST) (FIRST) representative. To obtain a list of FIRST member organizations and their constituencies send an email to docserver@first.org with an empty "subject" line and a message body containing the line "send first-contacts". ASSIST Information Resources: To be included in the distribution list for the ASSIST bulletins, send your Milnet (Internet) e-mail address to assist-request@assist.mil. Back issues of ASSIST bulletins, and other security related information, are available from the ASSIST BBS at 703-756-7993/1154 DSN 289-7993/1154, and through anonymous FTP from assist.mil (IP address 199.211.123.11). Note: assist.mil will only accept anonymous FTP connections from Milnet addresses that are registered with the NIC or DNS. If your system is not registered, you must provide your MILNET IP address to ASSIST before access can be provided. ASSIST Contact Information: PHONE: 800-357-4231 (or 703-756-7974 DSN 289), duty hours are 06:00 to 22:30 EDT (GMT -4) Monday through Friday. During off duty hours, weekends and holidays, ASSIST can be reached via pager at 800-791- 4857. The page will be answered within 30 minutes, however if a quicker response is required, prefix the phone number with "999". ELECTRONIC MAIL: Send to assist@assist.mil. ASSIST BBS: Leave a message for the "sysop". Reference herein to any specific commercial product, process, or service by trade name, trademark manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by ASSIST. The views and opinions of authors expressed herein shall not be used for advertising or product endorsement purposes. **************************************************************************** * * * 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. * * * **************************************************************************** PLEASE NOTE: Some users outside of the DOD computing communities may receive DDN Security bulletins. If you are not part of the DOD community, please contact your agency's incident response team to report incidents. Your agency's team will coordinate with DOD. The Forum of Incident Response and Security Teams (FIRST) is a world-wide organization. A list of FIRST member organizations and their constituencies can be obtained by sending email to docserver@first.org with an empty subject line and a message body containing the line: send first-contacts. This document was prepared as an service to the DOD community. Neither the United States Government nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government. The opinions of the authors expressed herein do not necessarily state or reflect those of the United States Government, and shall not be used for advertising or product endorsement purposes.