TO UNSUBSCRIBE: email "unsubscribe alert" in the body of your message to majordomoat_private Contact alert-ownerat_private for help with any problems! --------------------------------------------------------------------------- -----BEGIN PGP SIGNED MESSAGE----- ISS Security Advisory March 17, 1999 Short-Term High-Risk Vulnerability During Slackware 3.6 Network Installations Synopsis: Slackware Linux is one of the major distributions of the Linux operating system and supporting utilities. CD-ROM distributions are available from Walnut Creek, InfoMagic, LinuxMall, and other suppliers. It can also be downloaded from a number of archive and mirror sites. Some of these sites offer NFS access to Slackware (and other) distributions for direct installation from the network. During routine installation of Slackware Linux, there may be a period of time during which the system being installed is vulnerable to remote root login via telnet or other services. This period of time depends on human interaction and may vary from minutes to hours or more. This vulnerability may be subject to high-speed automated attacks against which individual interaction and correction can not compete. The vulnerability exists if Slackware is installed with the "net.i" boot image or if a network enabled kernel is installed during the initial installation. The CD boot image, when booting directly from CD-ROM, is not subject to this vulnerability. This problem has been addressed in post-3.6 packages available from the Slackware FTP site. Description: During a routine Slackware installation, Slackware completes the installation without prompting to set the root password. Upon completion of the installation, the system is rebooted. After the initial rebooting, the system boots with a NULL root password. When Slackware is initially installed and rebooted, inetd is active by default and both telnetd and rlogind are enabled in inetd.conf. The /etc/securetty file on the default Slackware install has remote root login enabled by including entries for ttyp0 through ttyp3. The combination of these three factors means that, immediately after rebooting following a Slackware installation, if the system was installed with a network enabled kernel such as "net.i", the system may be accessed via telnet or other services from anywhere on a reachable network as root without a password. Because of the order and speed at which different components are started, inetd is active and able to start a telnet session well in advance of any console login prompt. Securing the installation from this highly vulnerable state requires operator action to change the root password, disable the services, or disable remote root access. The most likely initial action is to establish a root password. This procedure may take from less than a minute to several hours, depending on the experience of the operator and other activities taking place at the time of the installation. Leaving the system unattended at the wrong time could be potentially hazardous and extend the period of vulnerability. The initial lilo prompt prior to boot has a two minute timeout and may give a false sense that it will not boot up automatically on its own. Leaving the system unattended at an apparently safe point can result in it autobooting unattended into a highly vulnerable state. There is no warning about this vulnerable time or the urgency in establishing a root password. Even though this simple security precaution would be obvious to experienced administrators, the urgency may not be obvious to inexperienced or first time installers. A test of this vulnerability used ping from another system on the same network to monitor a system during this reboot period. Immediately upon receiving a ping response, telnet was used to manually connect to the system and log in to the root account from the remote system. After logging in as root via telnet, the target system was checked and was, only then, just getting around to loading gpm and was nowhere near presenting a console login prompt. Several more seconds passed before it became possible to log in on the console. If a full install of all of the packages is performed, a common action by new or inexperienced users, the login and shell services are also installed and enabled from inetd. An attacker can break in using rsh or rlogin as root, even faster than with telnet. If a system can be identified as it is being installed, it is possible to use automatic tools to monitor the address and attack it as soon as it's available in its vulnerable condition. Connections to rlogin and telnet could transfer intrusion binaries and exploits to the system within the time the installer takes to login as root and begin to change the password. More elaborate attacks are possible since it is only necessary to log in prior to the root password being changed. This vulnerability is particularly dangerous in the case of remote installation via NFS from a central site, repository, or archive. In the case of network installations, it may possible through tracing, sniffing, scanning, traffic analysis, or NFS server accesses to identify a system being installed from a network Slackware Distribution. This discovery makes it possible to prepare tools to attack the identified system as soon as it is rebooted into its vulnerable state. This procedure could potentially be automated. Once a system has been identified by an attacker as a Slackware installation, it becomes possible to quickly re-attack the system if the system gets reinstalled with the same package. The re-attack can be executed and completed in less time than required for the system to reboot to a login prompt following re-installation of the OS. Recommendations: Do not perform any network based installations of Slackware Linux. If Slackware is the preferred installation distribution for Linux, it should be installed from local media only. Installation should take place while disconnected from a live network. Archive sites should disable NFS export of Slackware installation directories until updates become available. Users installing over NFS from such archive sites are particularly vulnerable to attack. When installing from local media, do not connect the installed system to a live network until after the system has been rebooted and the security conditions have been corrected as described below. Do not install with the "net.i" boot image or install a network enabled kernel until the root password has been changed, the securettys file has been corrected, or external services have been disabled. Correcting the Security Problems: Change the root password to a non-guessable password immediately upon initial reboot following installation. Disable remote root logins by removing the ptty entries from the /etc/securetty file. If not required for normal operation of the workstation, disable the telnet and ftp service in the inetd.conf file and restart inetd. If enabled by the particular installation, disable rlogin, rsh, and rexec services as well. Credits: This vulnerability was uncovered during research conducted by Michael H. Warfield of the ISS X-Force for an article on Installation Security for the LinuxWorld <http://www.linuxworld.com> security column "On the Ramparts." ________ Copyright (c) 1999 by Internet Security Systems, Inc. Permission is hereby granted for the electronic redistribution of this Security Advisory. It is not to be edited in any way without express consent of the X-Force. If you wish to reprint the whole or any part of this Security Advisory in any other medium excluding electronic medium, please e-mail xforceat_private for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. X-Force PGP Key available at: http://www.iss.net/xforce/sensitive.html as well as on MIT's PGP key server and PGP.com's key server. X-Force Vulnerability and Threat Database: http://www.iss.net/xforce Please send suggestions, updates, and comments to: X-Force <xforceat_private> of Internet Security Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: noconv iQCVAwUBNvA3nTRfJiV99eG9AQHuhwQAsEKKSu0BoMLOt4vPQUlEfY6ywOioLaMR TSQ4VAobl34Q4hDHCwVTGTeEOEDBiG4v6OmLhllrafX2/U2b+aCDwzCypqPGDY0G okSmrhsOKQ9GkqU1wVKVAu9cZxdFZfSsRI02dHaol+j03LCoBOBW/+h94ua5HuXG HDbTfpPmfPY= =QgMi -----END PGP SIGNATURE-----
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:39:14 PDT