[plug] Fw: ISSalert: ISS Security Advisory: Short-Term High-Risk Vulnerability During Slackware 3.6 Network Installations

Thu Mar 18 12:42:37 WST 1999

There is something to be said about TODAY's computer technology -
"Here today, gone tomorrow !!"
Download ICQ at http://www.icq.com
-----Original Message-----
From: X-Force <xforce at iss.net>
To: alert at iss.net <alert at iss.net>
Cc: X-Force <xforce at iss.net>
Date: Thursday, 18 March 1999 12:36
Subject: ISSalert: ISS Security Advisory: Short-Term High-Risk Vulnerability
During Slackware 3.6 Network Installations


>TO UNSUBSCRIBE: email "unsubscribe alert" in the body of your message to
>majordomo at iss.net  Contact alert-owner at iss.net 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 xforce at iss.net 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 <xforce at iss.net> 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-----
>