De acordo com as Leis 12.965/2014 e 13.709/2018, que regulam o uso da Internet e o tratamento de dados pessoais no Brasil, ao me inscrever na newsletter do portal DICAS-L, autorizo o envio de notificações por e-mail ou outros meios e declaro estar ciente e concordar com seus Termos de Uso e Política de Privacidade.
Colaboração: Rubens Queiroz de Almeida
Data de Publicação: 06 de Fevereiro de 1998
Estou anexando um documento que recebi já há algum tempo com relação a aspectos de segurança de sistemas AIX.
Embora antigo, este documento contém informações que podem ser úteis e válidas para qualquer versão do AIX e mesmo para outros sistemas operacionais.
Preparing your AIX System for SATAN
AIX Security Response Team
security@austin.ibm.com
.........................................................................=
I. Purpose of this document
II. AIX vulnerabilities probed by SATAN
1. NFS export to unprivileged programs
2. NFS export via portmapper
3. Unrestricted NFS export
4. NIS password file access
5. rexd access
6. Sendmail vulnerabilities
7. TFTP file access
8. Remote shell access
9. Unrestricted X server access
10. Writable FTP home directory
11. wu-ftpd vulnerability
III. More information on AIX security
IV. More information on internet security topics
V. CERT advisory on SATAN
.........................................................................=
I. Purpose of this document
.........................................................................=
Everyone is becoming increasingly aware of computer security
issues. No one wants to lose valuable information to unwanted
intruders. The SATAN tool was developed to help system administrators
secure all computers on their networks. The danger exists that this
tool could be used for unlawful purposes.
We want to help AIX users secure their systems so SATAN will not
cause any problems. This document is intended to help AIX users
understand each of the vulnerabilities probed by SATAN and learn what
they can do to secure their systems in each of these areas. Many
books and articles have been written on computer security
configuration issues and we will refer you to these articles
when appropriate.
.........................................................................=
II. AIX vulnerabilities probed by SATAN
.........................................................................=
.........................................................................=
1. NFS export to unprivileged programs
.........................................................................=
If the nfs mount daemon, rpc.mountd, is started with the -n
flag it allows mount requests to come from non-privileged ports.
This is used to allow some older versions of NFS to perform mounts.
It should not be used. The AIX default is to not use the -n flag.
For additional security use the nfso utility to turn on kernel port
checking. The command would be:
nfso -o nfs_portmon=1 (in AIX version 3 )
nfso -o portcheck=1 (in AIX version 4 )
The default in AIX is to NOT do kernel portchecking.
.........................................................................=
2. NFS export via portmapper
.........................................................................=
Access to filesystems via portmapper is disabled by default in
recent versions of AIX. To make sure you have a later version of
portmapper that fixes this problem, check to make sure your machine
has the fix for APAR IX32328. That fix has been included in PTFS
U419992 U419994 U419995.
Use the following aix cmd to determine if you have applied these ptfs:
$ lslpp -al U419992 U419994 U419995
.........................................................................=
3. Unrestricted NFS export
.........................................................................=
Entering a directory or filesystem in the /etc/export list without
specifying an access list allows any host who's IP address can be
resolved to mount the directory. This is not secure. The access list
should be specified when exporting filesystem objects.
Exports specifying root access or read/write access also are inherently
lower security and should be implemented with caution.
.........................................................................=
4. NIS password file access
.........................................................................=
The ability to view encrypted passwords when NIS is being used
and the ability to exploit the information can be curtailed and
to some extent prevented in a number of ways.
A) use a /var/yp/securenets file to restrict the NIS services to
trusted networks. (see the notes on securenets below).
B) Make the NIS domain name hard to guess and non-obvious. Employee
turnover or other security concerns may require domain renaming.
(use the chypdom command or smit chypdom to change domain names and
move the /var/yp/<domain_name> directory to the new name)
C) Require users to use non-trivial passwords.
Use of the /var/yp/securenets file:
The implementation of ypserv and ypxfrd that utilize the
securenets file was shipped in response to APAR ix32328
Some PTF's that contain that fix are:
U419992 U419994 and U419995.
Use the following aix cmd to determine if you have applied these ptfs:
$ lslpp -al U419992 U419994 U419995
Both the "ypserv" and "ypxfrd" use a /var/yp/securenets
file and, if present, only responds to IP addresses in the
range given. This file is only read when the daemons (both
ypserv & ypxfrd) start. To get a change in /var/yp/securenets
to take effect, one must kill and restart the daemons.
The format of the file is one or more lines of:
netmask netaddr
e.g.
255.255.0.0 128.30.0.0
255.255.255.0 128.311.10.0
In the 2nd example, the netmask is 255.255.255.0
and the network address is 128.311.10.0 . This
setup will only allow the ypserv to respond to
those IP addresses which are within the subnet
128.311.10 range.
An additional NIS security note is that allowing ypset to
reset ypbind binding lowers security. ypbind daemons
shipped in the fix for APAR IX43595 (in PTF U431006)
disallow ypset's as their default behavior and this is
strongly recommended.
Use the following aix cmd to determine if you have applied this ptf:
$ lslpp -al U431006
.........................................................................=
5. rexd access
.........................................................................=
The rexd server allows users to execute commands on remote servers
in an environment similar to that of the local system. No validation
of identity or access permission is performed. This behavior leads
many people to believe that the use of rexd is a security vulnerability.
There are currently no known defects in the rpc.rexd command which
adversely affect the security of the system. rpc.rexd is contained in
the bosnet.nfs.obj.client subsystem. The most recent PTF for that
subsystem as of the writing of this document is U436781.
Use the following aix cmd to determine if you have applied this ptf:
$ lslpp -al U436781
The lack of authentication of the identity of the invoker may present
a security exposure in an untrustworthy environment. You should weigh
the risks of a security exposure against the functionality provided when
you consider enabling this service.
The problems with rexd are inherent in the design of the server and
cannot be corrected easily. The security problems can be limited by
careful use of NFS exports on the client system and by disabling rexd
on the server.
IBM issued CA-92:05 on March 5, 1992 describing a problem with the
initial configuration of rexd on AIX 3.1 and AIX 3.2 systems. APAR
IX21353 was opened to correct this problem. The problem corrected by
this APAR no longer exists in AIX 3.2.5 or AIX 4.1.
In AIX 3.2.5 and 4.1 rexd is disabled by default when shipped.
.........................................................................=
6. Sendmail vulnerabilities
.........................................................................=
All AIX versions of /usr/sbin/sendmail are vulnerable to some of the
attacks described in CA-95:05. The official APARs resolving ALL known
AIX sendmail vulnerabilities are IX49257 (version 3.2) and IX49604
(version 4.1).
AIX users should obtain the emergency patch from Internet
ftp site software.watson.ibm.com. The file is located in
/pub/aix/sendmail/sendmail.tar.Z in compressed tar format.
Please follow the installation instructions in the sendmail.readme
file located in this same directory.
Currently, AIX versions 3.2 and 4.1 are based on sendmail version
5.64. Although this is an old version of sendmail, all known
sendmail security bugs are fixed by the emergency patch mentioned
previously.
If you permit automatic mail forwarding or programs that accept
mail messages, please be sure there is no way for these programs
to create a shell or send commands. This type of configuration can
create a security hole that could be exploited by an unfriendly user.
.........................................................................=
7. TFTP file access
.........................................................................=
The tftpd server allows users to retrieve files without requiring an
account on the remote server. Tftpd is commonly used by diskless=
systems
and X-stations as well. Tftp does not require the use of a user name or
password and therefore may grant access to system data when the identity
of the requestor has not been established. This may allow unknown users
to acquire restricted data or to modify user files.
There are currently no known defects in tftpd which adversely affect the
security of the system. The tftpd command is contained in the
bosnet.tcpip.obj.client subsystem. The most recent PTF for that=
subsystem
as of the writing of this document is U435114.
The lack of any authentication or identification of the requestor should
be considered when configuring tftpd. The tftp service may be=
restricted
using the /etc/tftpaccess.ctl file. This file is documented in
InfoExplorer under the tftpd command. This function was added to AIX=
v3.1
by APAR IX22628 and is available in the 2014 level PTF.
Tftp should be configured in /etc/inetd.conf to run as the user=
"nobody".
The following line is an example of how to do this.
tftp dgram udp wait nobody /etc/tftpd tftpd -n
THIS EXAMPLE WILL ALLOW REMOTE USERS TO WRITE FILES ON THE LOCAL SYSTEM.
If you have no requirement for granting write permission to remote users
you should consider removing the "-n" flag from the command line given
above.
The user "nobody" should own no files or directories on the system. The
only files or directories which the user "nobody" should be able to read
are those with read or write (and execute for directories) permission to
"other". Refer to the chmod command in InfoExplorer for details on how=
to
manage file and directory permissions. By properly restricting access=
to
"other", you will effectively limit the files and directories which=
tftpd
may access and modify.
IBM released CERT advisory CA:91-19 on October 17, 1991 for the tftpd
daemon. The vulnerability described in that advisory is corrected in=
all
releases of AIX v3.2 and AIX v4.
.........................................................................=
8. Remote shell access
.........................................................................=
The rsh and rlogin commands are used to establish sessions on remote
servers. Both commands operate in a similar manner from an access
perspective. The file /etc/hosts.equiv or a .rhosts file in the user's
home directory may be consulted to determine if access is granted. When
access is not automatically granted for the rlogin command the remote=
user
is prompted for a password.
The rshd server has had one security related defect. APAR IX45182
corrected a defect in which the "-l" option (used to control operation=
of
the server) did not work properly. This APAR was first delivered in PTF
U432655. This PTF should be applied to any system which has been
configured according to the instructions given below. This problem does
not exist on any release of AIX v4.
The rlogind server has had one significant security related defect. =
APARs
IX44254 and IX44367 corrected a defect in which any network user was=
able
to gain access to the remote system as any user. These APARs were first
delivered in PTFs U431620 and U431622 respectively. Both of these PTFs=
or
their superceding PTFs should be installed on all systems. This problem
does not exist on any release of AIX v4.
Two significant enhancements have been made to the rshd server. APAR
IX45701 added a facility for restricting use of rshd and rexecd on a=
user
by user basis. This feature may be useful for critical system accounts
which might be subject to attack via a network connection. This APAR=
was
first delivered in PTF U434068. APAR IX48235 added additional auditing
capability. This feature may be useful when connecting to unsecure
networks or when you are interested in monitoring rshd usage. A=
USER_Login
audit event will be created for each rshd invocation. This may be used=
in
conjunction with the TCPIP_access event to determine local user and=
remote
hostname for each rshd and rexecd. As of the writing of this document=
this
APAR has not been packaged into a PTF.
Both rshd and rlogind are subject to security violations related to
use of the /etc/hosts.equiv and $HOME/.rhosts files. This exposure can
be removed by adding the "-l" flag to the rshd and rlogind command
lines in /etc/inetd.conf. The following two lines are an example of how
you might do this.
shell stream tcp nowait root /etc/rshd rshd -l
login stream tcp nowait root /etc/rlogind rlogind -l
If you do not wish to grant remote network access to your system, you=
may
disable this facility entirely with lines similar to the following.
#shell stream tcp nowait root /etc/rshd rshd
#login stream tcp nowait root /etc/rlogind rlogind
Please refer to InfoExplorer for additional information on configuring
the /etc/inetd.conf file and the inetd daemon.
Should you choose to enable rshd and/or rlogind, the use of the
/etc/hosts.equiv and $HOME/.rhosts files creates a dependency on the
information in those files and the information which the servers use=
being
accurate. Errors in either file or spoofing of host addresses or names
are common causes of security exposures. When the network is not secure
or trustworthy, consider disabling these services for some or all users=
or
enabling the auditing subsystem to track possible attacks. You may also
wish to consider use of a firewall or some other form of packet filter=
to
restrict access to trustworthy hosts or networks.
InfoExplorer describes the proper configuration of the /etc/hosts.equiv
file. As a general rule, grant access to specific users and specific
hosts. You should monitor the existence of .rhosts files and insure=
that
users are educated about their proper use.
The telnet service may be more appropriate in an unsecured network
environment as it does not support the pre-authentication of users.
CERT advisory CA-94:09 was released on May 23, 1994 describing the=
security
exposure in the rlogin service.
Use the following aix cmd to determine if you have applied one of these=
ptfs:
$ lslpp -al U43xxxx
.........................................................................=
9. Unrestricted X server access
.........................................................................=
In 1993 CERT issued advisory CA-93:17 which documented a xterm=
vulnerability
in X11R5 and earlier versions of X11. This problem was resolved by the
following apars:
aixterm X11r4 : ix34738 - resolved by U417488 and U419246
aixterm X11r5 : ix40275 - resolved by ptf U425631
xterm X11r4 : ix40279 - resolved by ptf U425255 and U425228
xterm X11r5 : resolved by U493250 (3.2.5 Gold)
Use the following aix cmd to determine if you have applied these ptfs:
$ lslpp -al U4xxxxx
If you are using AIX 3.2, please make sure you have all these
ptfs applied to avoid potential security problems. These fixes
are shipped as part of the GOLD version of AIX 4.1. Because of X11's=
design,
the client/server can be accessed by any other host on the network. If
you are on the Internet, your display can be accessed by any machine in
the world. X11 security issues for AIX are similar to the X11 security=
problems
facing other X11 vendors. It is difficult to make X completely secure.
However, there are access control mechanisms which can be put in place
to help make your environment more secure. You should never use the
"xhost +" cmd because this will enable any remote user to read/write
screen information. Please remove all "xhost +" cmds from any file
or program on your system. A useful tool for limiting X access, please
see the /usr/bin/xauth
The best source of information on securing X is in : O'Reilly &=
Associates,Inc.
"X Window System Adminstrator's Guide". Specifically chapter 4 which=
goes into
detail about X security. The discussion in this chapter applies to the=
AIX
environment. In additon, the Common Desktop Enviroment (CDE) interface
available on AIX 4.1 uses XDMCP protocol discussed in this chapter.
.........................................................................=
10. Writable FTP home directory
.........................................................................=
In 1992, CERT issued advisory CA-92:09 about an AIX Anonymous FTP
Vulnerability. This problem was resolved by apar ix23944, which
was included in the GOLD release of AIX 3.2. Thus, AIX 3.2 and 4.1=
systems
are not vulnerable to this problem. The original problem was discovered
on AIX 3.1. If you are running AIX 3.1, please update to the latest
release of 3.1, which resolves this problem.
The following information can be very helpful:
- - The ftpd man page has explicit instructions for securely
configuring your anonymous FTP user and subtree.
- - The /usr/lpp/samples/tcpip/anon.ftp file can be used to securely
set up your anonymous account. (/usr/samples/tcpip/anon.ftp in AIX=
4.1)
- - The CERT tip found at ftp://info.cert.org/tech_tips/anonymous_ftp
contains applicable information.
.........................................................................=
11. wu-ftpd vulnerability
.........................................................................=
This problem only affects users running the wuarchive-ftpd.
If you do not have this modified version of ftpd, then you are
not vulnerable to this specific attack. If you are running the
wuarchive-ftpd, and your version is dated prior to April 8, 1993,
please take corrective action or remove this daemon.
You can obtain more information about this service via anonymous ftp
from wuarchive.wustl.edu (128.252.135.4).
This service is NOT distributed with AIX.
.........................................................................=
III. More information on AIX security
.........................................................................=
We publish an AIX security newsletter that is updated whenever
we have security information that affects AIX users.
To subscribe to the newsletter:
mail -s "subscribe security" aixserv@austin.ibm.com < /dev/null
If you have comments or questions about AIX security, or you
would like to notify us of a potential problem, please send mail
to security@austin.ibm.com.
To order an APAR from IBM in the U.S. call 1-800-237-5511.
APARs may be obtained outside the U.S. by contacting a
local IBM representative.
.........................................................................=
IV. More information on internet security topics
.........................................................................=
One of the best ftp sites for computer security information is
ftp://coast.cs.purdue.edu/pub. You might also want to check out
their WWW home page at http://www.cs.purdue.edu/coast. Their hotlist
of other security home pages is also very helpful.
Other WWW sites with pointers to useful security info:
http://csrc.ncsl.nist.gov/first
http://ciac.llnl.gov
There are many listservers and newsgroups that are completely
dedicated to the topic of computer security. You can find more
information about these by looking at some of the WWW sites mentioned
above.
.........................................................................=
V. CERT advisory on SATAN
.........................................................................=
CA-95:06 CERT Advisory
April 3, 1995
Security Administrator Tool for Analyzing Networks (SATAN)
----------------------------------------------------------
The CERT Coordination Center staff has examined beta version 0.51 of the
Security Administrator Tool for Analyzing Networks (SATAN). This advisory
contains information based on our review of this pre-release version. When the
official release is available, we will distribute an updated advisory. SATAN
is scheduled for release on April 5, 1995, at 14:00 GMT.
1. What is SATAN?
- ------------------
SATAN is a testing and reporting tool that collects a variety of information
about networked hosts. The currently available documentation can be found at
ftp://ftp.win.tue.nl/pub/security/satan_doc.tar.Z
SATAN gathers information about specified hosts and networks by examining
network services (for example, finger, NFS, NIS, ftp, and rexd). It can then
report this data in a summary format or, with a simple rule-based system,
investigate potential security problems. Problems are described briefly and
pointers provided to patches or workarounds. In addition to reporting
vulnerabilities, SATAN gathers general network information (network topology,
network services run, types of hardware and software being used on the
network). As described in the SATAN documentation, SATAN has an exploratory
mode that allows it to probe hosts that have not been explicitly specified.
Thus, SATAN could probe not only targeted hosts, but also hosts outside your
administrative domain.
Section 4 below lists the vulnerabilities currently probed by SATAN.
2. Potential Impact of SATAN
- ----------------------------
SATAN was designed as a security tool for system and network administrators.
However, given its wide distribution, ease of use, and ability to scan remote
networks, SATAN is also likely to be used to locate vulnerable hosts for
malicious reasons. It is also possible that sites running SATAN for a
legitimate purpose will accidentally scan your system via SATAN's exploratory
mode.
Although the vulnerabilities SATAN identifies are not new, the ability to
locate them with a widely available, easy-to-use tool increases the level of
threat to sites that have not taken steps to address those vulnerabilities. In
addition, SATAN is easily extensible. After it is released, modified versions
might scan for other vulnerabilities as well and might include code to
compromise systems.
3. How to Prepare for the Release of SATAN
- ------------------------------------------
* Examine your systems for the vulnerabilities described below and implement
security fixes accordingly.
* In addition to reading the advisories cited for specific vulnerabilities
below, consult the following documents for guidance on improving the
security of your systems:
ftp://info.cert.org/tech_tips/security_info
ftp://info.cert.org/tech_tips/anonymous_ftp
ftp://info.cert.org/tech_tips/packet_filtering
* Contact your vendor for information on available security patches, and
ensure that all patches have been installed at your site.
* Use the tools listed in Section 5 to assist you in assessing and improving
the security of your systems.
4. Vulnerabilities Probed by SATAN
- ----------------------------------
Listed below are vulnerabilities that beta version 0.51 of SATAN tests for,
along with references to CERT advisories and other documents where applicable.
Administrators should verify the state of their systems and perform corrective
actions as necessary. We cannot stress enough the importance of good network
configuration and the need to install all available patches.
1. NFS export to unprivileged programs
2. NFS export via portmapper
3. Unrestricted NFS export
See CERT advisory CA-94:15 and CA-94:15.README for security measures you
can take to address NFS vulnerabilities.
The following advisories also address problems related to NFS:
CA-94:02.REVISED.SunOS.rpc.mountd.vulnerability
CA-94:02.README
CA-93:15.SunOS.and.Solaris.vulnerabilities
CA-92:15.Multiple.SunOS.vulnerabilities.patches
CA-92:12.REVISED.SunOS.rpc.mountd.vulnerability
CA-91:21.SunOS.NFS.Jumbo.and.fsirand
4. NIS password file access
See CERT advisory CA-92:13 for information about SunOS 4.x machines
using
NIS, and CA-93:01 for information about HP machines.
5. rexd access
We recommend filtering the rexd service at your firewall and commenting
out rexd in the file /etc/inetd.conf.
See CERT advisory CA-92:05 for more information about IBM AIX machines
using rexd, and CA-91:06 for information about NeXT.
6. Sendmail vulnerabilities
See CERT advisory CA-95:05 and CA-95:05.README for the latest
information
we have published about sendmail.
7. TFTP file access
See CERT advisory CA-91:18 for security measures that address TFTP
access
problems. In addition, CA-91:19 contains information for IBM AIX users.
8. Remote shell access
We recommend that you comment out rshd in the file /etc/inetd.conf or
protect it with a TCP wrapper.
9. Unrestricted X server access
We recommend filtering X at your firewall. Additional advice about
packet filtering is available by anonymous FTP from
ftp://info.cert.org:/pub/tech_tips/anonymous_ftp
10. Writable FTP home directory
See CERT advisory CA-93:10.
Guidance on anonymous FTP configuration is also available from
ftp://info.cert.org:/pub/tech_tips/anonymous_ftp
11. wu-ftpd vulnerability
See CA-93:06, CA-94:07, and CA-94:07.README for more information about
ftpd.
Note: In addition to our FTP archive at info.cert.org, CERT documents are
available from the following sites, and others which you can locate
by using archie:
ftp://coast.cs.purdue.edu:/pub/mirrors/cert.org/cert_advisories
ftp://unix.hensa.ac.uk:/pub/uunet/doc/security/cert_advisories
ftp://ftp.luth.se:/pub/misc/cert/cert_advisories
ftp://ftp.switch.ch:/network/security/cert_advisories
ftp://corton.inria.fr:/CERT/cert_advisories
ftp://ftp.inria.fr:/network/cert_advisories
ftp://nic.nordu.net:/networking/security/cert_advisories
5. Currently Available Tools
- -----------------------------
The following tools are freely available now and can help you improve your
site's security before SATAN is released.
COPS and ISS can be used to check for vulnerabilities and configuration
weaknesses.
COPS is available from ftp://info.cert.org:/pub/tools/cops/*
ISS is available from
ftp://ftp.uu.net:/usenet/comp.sources.misc/volume39/iss
CERT advisory CA-93:14 and CA-93:14.README contain information about ISS.
TCP wrappers can provide access control and flexible logging to most network
services. These features can help you prevent and detect network attacks. This
software is available by anonymous FTP from
ftp://info.cert.org:/pub/tools/tcp_wrappers/*
The TAMU security package includes tools to check for vulnerabilities and
system configuration weaknesses, and it provides logging and filtering of
network services. This software is available by anonymous FTP from
ftp://net.tamu.edu:/pub/security/TAMU/*
The Swatch log file monitor allows you to identify patterns in log file
entries
and associate them with actions. This tool is available from
ftp://ee.stanford.edu:/pub/sources/swatch.tar.Z
6. Detecting Probes
- -------------------
One indication of attacks by SATAN, and other tools, is evidence of a heavy
scan of a range of ports and services in a relatively short time. Many UNIX
network daemons do not provide sufficient logging to determine if SATAN is
probing the system. TCP wrappers, the TAMU tools, and Swatch can provide the
logging you need.
7. Using SATAN
- ---------------
Running SATAN on your systems will provide you with the same information an
attacker would obtain, allowing you to correct vulnerabilities. If you choose
to run SATAN, we urge you to read the documentation carefully. Also,
note the following:
* It is easy to accidentally probe systems you did not intend to. If this
occurs, the probed site may view the probe(s) as an attack on their
system(s).
* Take special care in setting up your configuration file, and in selecting
the
probe level when you run SATAN.
* Explicitly bound the scope of your probes when you run SATAN. Under "SATAN
Configuration Management," explicitly limit probes to specific hosts and
exclude specific hosts.
* When you run SATAN, ensure that other users do not have read access to your
SATAN directory.
* In some cases, SATAN points to CERT advisories. If the link does not work
for you, try getting the advisories by anonymous FTP.
8. Getting more information about SATAN
- ---------------------------------------
As noted above, SATAN documentation is available from
ftp://ftp.win.tue.nl/pub/security/satan_doc.tar.Z
Additional documents are available through a mail server set up by one of the
authors.
Send mail to
majordomo@wzv.win.tue.nl
Put the following text in the body (not subject):
get satan mirror-sites
get satan release-plan
get satan description
get satan admin-guide-to-cracking.101
The last document contains "Improving the Security of Your Site by Breaking
Into It," a 1993 paper in which the authors give their rationale for creating
SATAN.
-------------------------------------------------------------------------
The CERT Coordination Center staff thanks Dan Farmer and Wieste Venema
for the
the opportunity to examine pre-release versions of SATAN. We also appreciate
the interaction with the response teams at AUSCERT, CIAC, and DFN-CERT, and
feedback from Eric Allman.
-------------------------------------------------------------------------
If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in the Forum of Incident
Response and Security Teams (FIRST).
If you wish to send sensitive incident or vulnerability information to
CERT staff by electronic mail, we strongly advise that the e-mail be
encrypted. The CERT Coordination Center can support a shared DES key, PGP
(public key available via anonymous FTP on info.cert.org), or PEM (contact
CERT staff for details).
Internet E-mail: cert@cert.org
Telephone: +1 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4),
and are on call for emergencies during other hours.
Fax: +1 412-268-6989
Postal address: CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
USA
CERT advisories and bulletins are posted on the USENET newsgroup
comp.security.announce. If you would like to have future advisories and
bulletins mailed to you or to a mail exploder at your site, please send mail
to cert-advisory-request@cert.org.
Past advisories, CERT bulletins, information about FIRST representatives, and
other information related to computer security are available for anonymous
FTP from info.cert.org.
Copyright 1995 Carnegie Mellon University
This material may be reproduced and distributed without permission provided it
is used for noncommercial purposes and the copyright statement is included.
CERT is a service mark of Carnegie Mellon University.
-------------------------------------------------------------------------
-------------------------------------------------------------------------
AIX Service Bulletin
September 8, 1994
International Business Machines Corporation
RISC System/6000 Division
AIX Service and Support
11400 Burnet Road
Austin, TX 78758i
Subject: Potential Security Exposure
IBM has become aware of a potential security exposure in all releases
and levels of AIX Version 3 that could allow local and remote users to
obtain unauthorized root authority. This unauthorized root authority
may be obtained through the use of:
o The vi editor
o Remote login
o The batch (bsh) queue
o Network Information Service (NIS)
You may obtain emergency fixes to eliminate the potential security
exposure without disabling the remote login, batch queue, or NIS
functions from the IBM Support Center or via anonymous FTP from:
software.watson.ibm.com:/pub/aix/security.tar
Officially released fixes, IX43595, IX44254, IX44381, and IX44685,
can be obtained using FixDist in the U.S., or from the IBM Support
Center.
Customers can also chose to perform the procedures outlined on the
attached pages to immediately eliminate the potential exposure,
although this will disable the remote login, batch queue, and NIS
fucntions.
Additionally, IBM has become aware of a potential problem affecting
only AIX Version 3.2.5 that could allow a user program to abnormally
terminate ("crash") a system, requiring a system reboot. A fix for
this problem, IX44274, can be obtained using FixDist in the U.S., or
from the IBM Support Center.
For information on contacting the IBM Support Center, call
800-IBM-4FAX and request document number 1760.
Procedure to Eliminate AIX Version 3 Unauthorized Root Authority
Security Exposure
1. Login as root
2. To ensure that root's shell is /bin/ksh, use the following
command:
/bin/ksh
3. To ensure that your current directory is root (/), use the
following command:
cd /
The following steps eliminate the ability to obtain unauthorized
root authority through the use of the vi editor. The vi editor may
be used to accomplish these steps.
4. Determine the version of the vi editor using the following
command:
strings /usr/bin/vi | grep ex_data
If the second column of output is '1.6' or '1.7', then perform
steps 5 and 6, otherwise skip to step 7.
5. Create or edit the existing .exrc file in the home directory of
every user, starting with root, and insert the following as the
first line:
set nosourceany noexrc
6. Set the owner and permissions of the .exrc file using the following
command, substituting the user name for '<user>':
chown <user> ~<user>/.exrc=
chmod 600 ~<user>/.exrc=
The following steps eliminate the ability to obtain unauthorized root
authority through the use of remote login by disabling remote login
using the rlogin and rsh commands.
7. Edit the /etc/inetd.conf file. If the following line exists,
comment it out by inserting a # in the first column of the line:
login stream tcp nowait root /etc/rlogind rlogind
8. Enter the following commands to make the change take immediate
effect:
/usr/bin/inetimp
/usr/bin/refresh -s inetd
The following step eliminates the ability to obtain unauthorized root
authority through the use of the batch (bsh) queue by disabling the
batch queue.
9. Enter the following command to disable the batch queue:
/usr/bin/chque -qbsh -a"up = FALSE"
The following steps eliminate the ability to obtain unauthorized root
authority through the use of NIS by disabling NIS on the client.
10. Copy the /etc/hosts, /etc/passwd, /etc/security/passwd, /etc/group,
/etc/security/group and any other NIS served files from the NIS
master to the NIS client.
11. Enter the following command on the NIS client to disable NIS on
the client:
/usr/etc/yp/rmyp -c
This policy contains information about your privacy. By posting, you are declaring that you understand this policy:
This policy is subject to change at any time and without notice.
These terms and conditions contain rules about posting comments. By submitting a comment, you are declaring that you agree with these rules:
Failure to comply with these rules may result in being banned from submitting further comments.
These terms and conditions are subject to change at any time and without notice.
Comentários