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

S-99-22.asc

S-99-22.asc
Posted Jan 10, 2000

Subject SGI arrayd default security configuration Date 25-Jul-99

SHA-256 | 3fc1f3294c8f9f09250ee5076603b61dae624fc7e4712c1969205dac5f7c9ecb

S-99-22.asc

Change Mirror Download
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

===============================================================================
>> CERT-NL, 01-Mar-2000 <<
>> All CERT-NL information has been moved to http://cert.surfnet.nl. Links <<
>> to CERT-NL information contained in this advisory are therefore outdated. <<
>> <<
>> CERT-NL also has stopped the CERT-CC-Mirror service. Due to this the <<
>> links to the CERT-CC mirror are obsolete. Visit the CERT-CC site for the <<
>> complete CERT-CC advisory texts: http://www.cert.org <<
===============================================================================
===============================================================================
Security Advisory CERT-NL
===============================================================================
Author/Source : Egon Verharen Index : S-99-22
Distribution : World Page : 1
Classification: External Version: 1
Subject : SGI arrayd default security configuration Date : 25-Jul-99
===============================================================================

By courtesy of The U.S. Department of Energy Computer Incident Advisory
Capability we received information on a vulnerability in SGI's arrayd default
security configuration. The default security configuration of arrayd from
array.auth(4) does not provide adequate protection against attack when the array
of clustered systems are placed on an untrusted network.

The risk is high for a root compromise of vulnerable systems.

CERT-NL recommends that the measures outlined in this advisory be implemented on
ALL vulnerable SGI systems.

==============================================================================
__________________________________________________________

The U.S. Department of Energy
Computer Incident Advisory Capability
___ __ __ _ ___
/ | /_\ /
\___ __|__ / \ \___
__________________________________________________________

INFORMATION BULLETIN
SGI arrayd default security configuration
SGI Security Advisor 19990701-01-P

July 22, 1999 23:00 GMT Number J-052
______________________________________________________________________________
PROBLEM: The default security configuration of arrayd from
array.auth(4) does not provide adequate protection against
attack when the array of clustered systems are placed on an
untrusted network.
PLATFORM: IRIX systems:
6.2, 6.3, 6.4, 6.5, 6.5.1, 6.5.2, 6.5.3, and 6.5.4.
UNICOS systems:
9.0.X.X, 10.0, 10.0.0.1, 10.0.0.2, 10.0.0.3, 10.0.0.4,
10.0.0.5, and 10.0.0.6.
DAMAGE: Exploiting this vulnerability can lead to a root compromise.
SOLUTION: Apply the workaround given in the bulletin below. This issue
will be corrected in future releases of UNICOS and the IRIX
applications CD.
______________________________________________________________________________
VULNERABILITY The risk is high for a root compromise of vulnerable systems.
ASSESSMENT: SGI HIGHLY RECOMMENDS that these measures be implemented on
ALL vulnerable SGI systems.
______________________________________________________________________________

[ Start Silicon Graphics Advisory ]

______________________________________________________________________________
SGI Security Advisory

Title: SGI arrayd default security configuration
Number: 19990701-01-P
Date: July 19, 1999
______________________________________________________________________________

SGI provides this information freely to the SGI user community for its
consideration, interpretation, implementation and use. SGI recommends
that this information be acted upon as soon as possible.

SGI provides the information in this Security Advisory on an "AS-IS" basis
only, and disclaims all warranties with respect thereto, express, implied
or otherwise, including, without limitation, any warranty of merchantability
or fitness for a particular purpose. In no event shall SGI be liable for
any loss of profits, loss of business, loss of data or for any indirect,
special, exemplary, incidental or consequential damages of any kind arising
from your use of, failure to use or improper use of any of the instructions
or information in this Security Advisory.
______________________________________________________________________________


+---------------------+
|-- Issue Specifics --|
+---------------------+

The SGI Array Services provide a mechanism to simplify administering
and managing an array of clustered systems. The arrayd(1m) program is part
of the array_services(5) and is known as the array services daemon.

Unfortunately, the default security configuration of arrayd from
array.auth(4) does not provide adequate protection against attack when the
array of clustered systems are placed on an untrusted network. For example,
if the systems are placed on the Internet without a firewall, there is a
possible root compromise of all clustered systems in the array when the
default array.auth configuration is used.

SGI has investigated the issue and recommends the following steps for
neutralizing the exposure. It is HIGHLY RECOMMENDED that these measures
be implemented on ALL vulnerable SGI systems. This issue will be
corrected in future releases of UNICOS and the IRIX applications CD.


+------------+
|-- Impact --|
+------------+

On IRIX, the SGI Array services consists of an inst image called arraysvcs.
The arraysvcs inst image is installed by default on IRIX 6.4-6.5.4 from the
IRIX Applications CD and available as an optional product for IRIX 6.2-6.3.

All sites using array services on UNICOS 9.0 or later are vulnerable.
Array services are not supported on UNICOS/mk, so it is not vulnerable.

The default arrayd.auth configuration file has authentication disabled.

A local user account on the vulnerable array is not required in order to
exploit the arrayd daemon. The arrayd daemon can be exploited remotely over
an untrusted network.

The arrayd vulnerability can lead to a root compromise on an untrusted
network if the array services are running and the arrayd.auth configuration
file has not been changed to enable authentication.

It is believed that this vulnerability in arrayd has not been publicly
discussed outside of SGI.


+------------------------+
|-- Temporary Solution --|
+------------------------+

The steps below can be used to either 1) remove the vulnerability by
removing the Array Services if they are not being used or 2) enable
authorization using a appropriately setup arrayd.auth(4) configuration
file.


+-+-+-+-+
|I R I X|
+-+-+-+-+

1) Become the root user on the system.

% /bin/su -
Password:
#


2) Check to see if the system is running the SGI Array Services.

# chkconfig

Flag State
==== =====
array off

If the Array Services are disabled, the system is not vulnerable
to the arrayd vulnerability.

If required, the arraysvcs inst image can be removed using
following command:

=================
**** WARNING ****
=================

This will completely remove the SGI Array Services programs

# versions remove arraysvcs



3) Edit the default arrayd.auth file to enable authentication.


# vi /usr/lib/array/arrayd.auth


4) Comment out authentication entry in the arrayd.auth file.
This will enable SIMPLE authentication.


# AUTHENTICATION NONE


5) Configure SIMPLE authentication in the arrayd.auth file
if array services are needed on untrusted networks.
See arraysvcs release notes or arrayd.auth man page for more
information on configuring SIMPLE authentication.


6) Restart the arrayd daemon so that it will read the new configuration
files.

# /etc/init.d/array restart


7) Return to previous level.

# exit
%



+-+-+-+-+-+-+
|U N I C O S|
+-+-+-+-+-+-+

1) Become the root user on the system.

% /bin/su -
Password:
#


2) Edit the default arrayd.auth file to enable authentication.


# vi /usr/lib/array/arrayd.auth


3) Replace AUTH NONE entry with AUTH SIMPLE in the arrayd.auth file.
This will enable SIMPLE authentication.

Find

AUTH NONE

Replace with

AUTH SIMPLE


4) Configure SIMPLE authentication in the arrayd.auth file
if array services are needed on untrusted networks.
See arrayd.auth man page for more
information on configuring SIMPLE authentication.


5) Restart the arrayd daemon so that it will read the new configuration
files.

# /etc/init.d/array restart


6) Return to previous level.

# exit
%


+--------------+
|-- Solution --|
+--------------+

+-+-+-+-+
|I R I X|
+-+-+-+-+

On IRIX, the Array Services security issue is scheduled to be fixed in the
next release of the IRIX applications CD.

OS Version Vulnerable? Patch # Other Actions
---------- ----------- ------- -------------

IRIX 3.x-5.X no Note 1
IRIX 6.0.x no Note 1
IRIX 6.1 no Note 1
IRIX 6.2 yes not avail Note 2 & 3
IRIX 6.3 yes not avail Note 1 & 3
IRIX 6.4 yes not avail Note 1 & 3
IRIX 6.5 yes not avail Note 3 & 4
IRIX 6.5.1 yes not avail Note 3 & 4
IRIX 6.5.2 yes not avail Note 3 & 4
IRIX 6.5.3 yes not avail Note 3 & 4
IRIX 6.5.4 yes not avail Note 3 & 4

NOTES

1) This version of the IRIX operating system has retired.
Upgrade to currently supported IRIX operating system.
See http://support.sgi.com/news/irix2.html for more information.
2) This version of the IRIX operating system is in maintenance mode.
See http://support.sgi.com/news/irix1.html for more information.
3) See "Temporary Solution" section.
4) If you have not received an IRIX 6.5.X CD for IRIX 6.5, contact your
SGI Support Provider or download the IRIX 6.5.X Maintenance Release
Stream from http://support.sgi.com/ or
ftp://support.sgi.com/support/relstream/


+-+-+-+-+-+-+
|U N I C O S|
+-+-+-+-+-+-+

OS Versions Vulnerable? Other Actions
----------- ----------- -------------
UNICOS /mk No
UNICOS 9.0.X.X Yes Note 1
UNICOS 10.0 Yes Note 1
UNICOS 10.0.0.1 Yes Note 1
UNICOS 10.0.0.2 Yes Note 1
UNICOS 10.0.0.3 Yes Note 1
UNICOS 10.0.0.4 Yes Note 1
UNICOS 10.0.0.5 Yes Note 1
UNICOS 10.0.0.6 Yes Note 1


NOTES

1) See "Temporary Solution" section.


+----------------------+
|-- Acknowledgments ---|
+----------------------+

SGI wishes to thank the CERT Coordination Center and Yuri Volobuev
for their assistance in this matter.


+---------------------------------------+
|-- SGI Security Information/Contacts --|
+---------------------------------------+

If there are questions about this document, email can be sent to
cse-security-alert@sgi.com.

The primary SGI anonymous FTP site for security information and patches
is sgigate.sgi.com (204.94.209.1). Security information and patches
are located under the directories ~ftp/security and ~ftp/patches,
respectively. The SGI Security Headquarters Web page is accessible at
the URL http://www.sgi.com/Support/security/security.html.

For issues with the patches on the FTP sites, email can be sent to
cse-security-alert@sgi.com.

For assistance obtaining or working with security patches, please
contact your SGI support provider.

------oOo------

SGI provides a comprehensive customer World Wide Web site. This site is
located at http://www.sgi.com/Support/security/security.html.

------oOo------

For reporting *NEW* SGI security issues, email can be sent to
security-alert@sgi.com or contact your SGI support provider. A
support contract is not required for submitting a security report.

______________________________________________________________________________
[ End Silicon Graphics Advisory ]

______________________________________________________________________________

CIAC wishes to acknowledge Silicon Graphics for the information contained in
this bulletin.
______________________________________________________________________________


==============================================================================
CERT-NL is the Computer Emergency Response Team for SURFnet customers. SURFnet
is the Dutch network for educational, research and related institutes. CERT-NL
is a member of the Forum of Incident Response and Security Teams (FIRST).

All CERT-NL material is available under:
http://cert.surfnet.nl/

In case of computer or network security problems please contact your local
CERT/security-team or CERT-NL (if your institute is NOT a SURFnet customer
please address the appropriate (local) CERT/security-team).

CERT-NL is one/two hour(s) ahead of UTC (GMT) in winter/summer,
i.e. UTC+0100 in winter and UTC+0200 in summer (DST).

Email: cert-nl@surfnet.nl ATTENDED REGULARLY ALL DAYS
Phone: +31 302 305 305 BUSINESS HOURS ONLY
Fax: +31 302 305 329 BUSINESS HOURS ONLY
Snailmail: SURFnet bv
Attn. CERT-NL
P.O. Box 19035
NL - 3501 DA UTRECHT
The Netherlands

NOODGEVALLEN: 06 22 92 35 64 ALTIJD BEREIKBAAR
EMERGENCIES : +31 6 22 92 35 64 ATTENDED AT ALL TIMES
CERT-NL'S EMERGENCY PHONENUMBER IS ONLY TO BE USED IN CASE OF EMERGENCIES:
THE SURFNET HELPDESK OPERATING THE EMERGENCY NUMBER HAS A *FIXED*
PROCEDURE FOR DEALING WITH YOUR ALERT AND WILL IN REGULAR CASES RELAY IT
TO CERT-NL IN AN APPROPRIATE MANNER. CERT-NL WILL THEN CONTACT YOU.
===============================================================================

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1i

iQA/AwUBOL6IrTSYjBqwfc9jEQLR4wCeOuqNfPcDXBlEgthVNBkyKrbHBs8AoPeU
4mAzmr8S2RYOTIbyPeTeSSdv
=mvKc
-----END PGP SIGNATURE-----
Login or Register to add favorites

File Archive:

April 2024

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

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close