exploit the possibilities

iss.99-03-17.slackware

iss.99-03-17.slackware
Posted Mar 18, 1999

iss.99-03-17.slackware

systems | linux, slackware
MD5 | c5c4dfd42ee92900cad09360eb600ce5

iss.99-03-17.slackware

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!
---------------------------------------------------------------------------


-----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@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@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-----
Login or Register to add favorites

File Archive:

January 2022

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

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2020 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close