exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New


Posted Mar 18, 1999


systems | linux, slackware
SHA-256 | ee9264bdde5ee3e21c805d9bd17cd17851c6ba7691101d680a63fa2cae045b11


Change Mirror Download

From xforce@iss.net Wed Mar 17 23:52:37 1999
From: X-Force <xforce@iss.net>
To: alert@iss.net
Cc: X-Force <xforce@iss.net>
Date: Wed, 17 Mar 1999 18:21:22 -0500 (EST)
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@iss.net Contact alert-owner@iss.net for help with any problems!


ISS Security Advisory
March 17, 1999

Short-Term High-Risk Vulnerability During Slackware 3.6 Network


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.


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

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.


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.


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


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@iss.net for permission.

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@iss.net> of Internet Security Systems, Inc.

Version: 2.6.3a
Charset: noconv

Login or Register to add favorites

File Archive:

September 2023

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Sep 1st
    2 Files
  • 2
    Sep 2nd
    21 Files
  • 3
    Sep 3rd
    0 Files
  • 4
    Sep 4th
    17 Files
  • 5
    Sep 5th
    34 Files
  • 6
    Sep 6th
    29 Files
  • 7
    Sep 7th
    11 Files
  • 8
    Sep 8th
    25 Files
  • 9
    Sep 9th
    0 Files
  • 10
    Sep 10th
    0 Files
  • 11
    Sep 11th
    26 Files
  • 12
    Sep 12th
    23 Files
  • 13
    Sep 13th
    17 Files
  • 14
    Sep 14th
    22 Files
  • 15
    Sep 15th
    16 Files
  • 16
    Sep 16th
    0 Files
  • 17
    Sep 17th
    0 Files
  • 18
    Sep 18th
    19 Files
  • 19
    Sep 19th
    60 Files
  • 20
    Sep 20th
    23 Files
  • 21
    Sep 21st
    15 Files
  • 22
    Sep 22nd
    8 Files
  • 23
    Sep 23rd
    0 Files
  • 24
    Sep 24th
    0 Files
  • 25
    Sep 25th
    17 Files
  • 26
    Sep 26th
    3 Files
  • 27
    Sep 27th
    0 Files
  • 28
    Sep 28th
    0 Files
  • 29
    Sep 29th
    0 Files
  • 30
    Sep 30th
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Security Services
Hosting By