COMMAND
network installation
SYSTEMS AFFECTED
Slackware 3.6 Network Installations
PROBLEM
Following is based on ISS Security Advisory. 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.
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.
SOLUTION
This problem has been addressed in post-3.6 packages available
from the Slackware FTP site. 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.
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.