发信人: Gamble_Tan@bbs.ustc.edu.cn (岫云), 信区: cnunix
标 题: SGI security FAQ
发信站: 中国科大BBS站 (Sat Jun 20 06:17:39 1998)
转信站: Lilac!ustcnews!ustcbbs
SGI security Frequently Asked Questions (FAQ)
This is one of the Silicon Graphics FAQ series, which consists of:
SGI admin FAQ - IRIX system administration
SGI apps FAQ - Applications and miscellaneous programming
SGI audio FAQ - Audio applications and programming
SGI diffs FAQ - Changes to the other FAQs since the last posting
SGI graphics FAQ - Graphics and user environment customization
SGI hardware FAQ - Hardware
SGI impressario FAQ - IRIS Impressario
SGI inventor FAQ - IRIS Inventor
SGI misc FAQ - Introduction & miscellaneous information
SGI movie FAQ - Movies
SGI performer FAQ - IRIS Performer
SGI pointer FAQ - Pointer to the other FAQs
SGI security FAQ - IRIX security
Read the misc FAQ for information about the FAQs themselves. Each FAQ is
posted to comp.sys.sgi.misc and to the news.answers and comp.answers
newsgroups (whose purpose is to store FAQs) twice per month. If you
can't find one of the FAQs with your news program, you can get it from
ftp://viz.tamu.edu/pub/sgi/faq/
ftp://rtfm.mit.edu/pub/usenet/news.answers/sgi/faq/
(rtfm.mit.edu is home to many other FAQs and informational documents,
and is a good place to look if you can't find an answer here.) The FAQs
are on the World Wide Web at
http://www-viz.tamu.edu/~sgi-faq/
If you can't use FTP or WWW, send mail to mail-server@rtfm.mit.edu with
the word 'help' on a line by itself in the text, and it will send you a
document describing how to get files from rtfm.mit.edu by mail. Send the
command 'send usenet/news.answers/sgi/faq/misc' to get the SGI misc FAQ,
and similarly for the other FAQs. Send the command 'send
usenet/news.answers/internet-services/access-via-email' to get the
"Accessing the Internet by E-Mail FAQ".
You may distribute the SGI FAQs freely and we encourage you to do so.
However, you must keep them intact, including headers and this notice,
and you must not charge for or profit from them. Contact us for other
arrangements. We can't be responsible for copies of the SGI FAQs at
sites which we do not control, and copies published on paper or CD-ROM
are certain to be out of date. The contents are accurate as far as we
know, but the usual disclaimers apply. Send additions and changes to
sgi-faq@viz.tamu.edu.
Topics covered in this FAQ:
---------------------------
-1- Where can I learn about IRIX and Unix security?
-2- How can I check my system for security problems?
-3- How can I configure IRIX to be more secure?
-4- How can I log more information about logins?
-5- How can I make an anonymous or restricted FTP account?
-6- How can I get X authorization to work?
-7- What security-related bugs does IRIX have?
-8- I think I've found a security hole in IRIX; whom should I notify?
-9- How can I get around the root and/or PROM passwords?
-10- What firewalls are available on SGI/IRIX platforms?
----------------------------------------------------------------------
Subject: -1- Where can I learn about IRIX and Unix security?
Date: 4 Jun 1997 00:00:01 EST
IRIX: Look in ftp://sgigate.sgi.com/Security/ and at
http://www.sgi.com/Support/Secur/security.html for SGI security
advisories and patches. SGI also runs a mailing list called
"wiretap" for dissemination of IRIX security advisories from SGI;
its subscription address is <wiretap-request@sgi.com>. An article in
the Jul/Aug 1994 Pipeline discusses general Unix security with some
IRIX-specific aspects.
Unix in general: Look in ftp://ftp.cert.org/,
ftp://ciac.llnl.gov/pub/ciac/ and http://www.8lgm.org/ for CERT, CIAC
and 8lgm material (respectively) and general security information and
tools. If you have a lot of spare time, consider the
comp.security.unix newsgroup and/or the bugtraq mailing list
(listproc@netspace.org, archived at http://www.geek-girl.com/bugtraq/)
------------------------------
Subject: -2- How can I check my system for security problems?
Date: 04 May 1996 00:00:01 EST
Get Nate Sammons <nate@vis.colostate.edu>' 'rscan' (formerly
'securscan') from ftp://ftp.vis.colostate.edu/pub/rscan/ (and see its
documentation etc. at http://www.vis.colostate.edu/rscan/). It checks
for many bugs and problems, both specific to IRIX and generic to Unix.
Unfortunately, it has not been updated since April 1995 and will not
detect most holes discovered since then. You might also want to try a
generic Unix security-checking tool such as COPS, tiger or SATAN
and/or a password checker such as Crack. SGI's security page
referenced above gives their locations.
------------------------------
Subject: -3- How can I configure IRIX to be more secure?
Date: 30 Mar 1996 00:00:01 EST
Several aspects of SGI's default IRIX configuration were chosen for
convenience, not security. Unless your machine is not networked, you
may be more concerned about security than SGI assumed. Note that
these items have been discussed on Usenet many times, and Usenet
chatter is not a good way to change SGI policy. If they bother you,
complain to your sales rep and then fix them yourself as follows.
Under any version of IRIX,
- Several accounts come without passwords, including (but not limited
to) guest, 4Dgifts, demos, tutor, tour and particularly lp. Examine
/etc/passwd and lock all unnecessarily open accounts. Note that 1)
parts of IRIX (e.g. 'inst') use the open guest account by default,
and 2) remote 'lp' clients need access to the lp account to print,
so you'll need to make other arrangements. Completists may wish to
read CERT advisory CA-95:15, at
ftp://info.cert.org/pub/cert_advisories/CA-95%3A15.SGI.lp.vul, and
SGI advisory 19951002-01-I, at
ftp://sgigate.sgi.com/Security/19951002-01-I.
- 'xdm' does 'xhost +' by default when you log in. This allows anyone
to open windows on your display and even to record what you type at
your keyboard. Close this hole by removing the 'xhost +' from
/usr/lib/X11/xdm/Xsession, /usr/lib/X11/xdm/Xsession-remote and (in
IRIX 5.x) /usr/lib/X11/xdm/Xsession.dt. In IRIX 5.2 and later you
can use X authorization to control access to remote displays; see
below. In IRIX 5.1.x and earlier X authorization doesn't work, so
you'll need to use 'xhost' judiciously to get to remote displays:
say 'xhost +localhost' to run DGL programs and 'xhost +otherhost' to
display remote X programs.
- At least some of the possible default values of the PATH
environment variable begin with the current directory. (The system
interprets either a period or the empty string in any component of
PATH as the current directory. PATH is colon-separated, so if it
begins with a colon the first component is the empty string.) This
exposes you to Trojan horse programs. Set PATH to a safe value
(remove the current directory, or at least move it to the end) in
/etc/cshrc and/or /etc/profile for regular users and /.login for
root.
- By default, /etc/config/ypbind.options contains the -ypsetme
option. This allows someone who can fake your IP address to change
your YP binding. Remove the -ypsetme option to close the hole and
add the -s option for a little extra protection. Comment out the
invocations of 'ypset' in /var/yp/make.script and /var/yp/ypmake to
avoid error messages. If your site runs ypbind with the -v
(verbose) option, you may also want to add 'YPSET=true' to
/etc/config/ypmaster.options and comment out the 'ypset' line in
/var/yp/ypmake. See the ypbind(1) and ypset(1) manpages for more.
- If you use SLIP (see slip(1M)), be sure that SLIP accounts' home
directories are not world-writable. SLIP accounts are uid 0, so
it's bad if just anyone can mess with their .forward files and the
like. /tmp, which is recommended in the "IRIX Advanced Site and
Server Administration Guide", is necessarily world-writable and a
bad choice. You may want to make an empty, root-owned, mode 755
directory to the effect of /usr/slip and use that. Any number of
SLIP accounts can use a single home directory without conflict.
- Add '-a' to the rlogind and rshd lines in /etc/inetd.conf to require
remote hostnames and addresses to match. You *might* want to
disallow .rhosts files by adding the '-l' flag as well, but this
removes real functionality and should not be done without reason.
See the rlogind(1M) and rshd(1M) manpages. Note that rlogind's '-l'
flag does not work in IRIX 5.2. It does work in IRIX 5.3.
- The default root crontab in current IRIXes
(/var/spool/cron/crontabs/root) creates the SYSLOG and cron log with
group and world read permission. Change the '033' on lines 25 and 27
to '077' to prevent non-superusers from reading these files.
- By default, xdm looks for X terminal login requests on port
177. This is no different (for security purposes) than allowing
rlogin or telnet connections, but it might be undesirable in some
environments. Edit /var/X11/xdm/Xaccess to restrict this access,
e.g. by placing a `!' in front of each of the two lines which begin
with an asterisk to prevent all XDMCP requests.
- /etc/init.d/rmtmpfiles resets the permissions on /tmp and /var/tmp
at every bootup. By default, permissions are set to 1777; the '1'
means sticky, so one user can't remove another's temporary files. If
one does 'chkconfig nostickytmp on', permissions are set to 777 and
any user can remove another's temporary files. Don't do this: it
allows a variety of attacks involving race conditions in setuid
programs. A related class of attacks is described in
ftp://ciac.llnl.gov/pub/ciac/bulletin/f-27.permissions-on-tmp.asc,
but note that Sun's tmpfs is not an essential component of the hole.
- Non-root users can give away files. This can be used to defeat
accounting and quotas. Set the 'restricted_chown' kernel variable to
1 to allow only root to give away files. This may break some
programs which depend on unrestricted chown, e.g. /bin/mail (when
delivering to an NFS volume without root access) as discussed in the
admin FAQ. (Thanks to Jonathan Rozes <jrozes@tufts.edu> for this and
the next item.)
- NFS connections to unprivileged ports are accepted by default. Set
the 'nfs_portmon' kernel variable to 1 to reject NFS connections
to unprivileged ports.
- /etc/inetd.conf enables some unnecessary services. The 'echo'
and 'chargen' services can allow a denial-of-service attack, as
described, for example, in CERT advisory CA-96.01, at
ftp://ftp.cert.org/pub/cert_advisories/CA-96.01.UDP_service_denial.
To disable those particular services, comment out the lines which
begin with their names in /etc/inetd.conf and 'killall -HUP inetd'.
You may want to disable other unused UDP-based services as well.
- Many devices have permissions which might allow a user to monitor
another user via audio or video input, including
/dev/audio
/dev/dmrb
/dev/hdsp/*
/dev/vid
/dev/video
Bill Paul <wpaul@ctr.columbia.edu>'s solution is to add the
following to /usr/lib/X11/xdm/Xstartup
chmod 600 /dev/audio /dev/hdsp/* /dev/video /dev/vid /dev/dmrb
chown $USER /dev/audio /dev/hdsp/* /dev/video /dev/vid /dev/dmrb
and the following to /usr/lib/X11/xdm/Xreset
chmod 600 /dev/audio /dev/hdsp/* /dev/video /dev/vid /dev/dmrb
chown root /dev/audio /dev/hdsp/* /dev/video /dev/vid /dev/dmrb
(Simon ? <simon@instrumatic.ch> pointed out that the chmod should
precede the chown to avoid a race condition.)
- Read the rest of the entries in this section and make the changes
they describe if appropriate.
Under IRIX 5.x or later only,
- Turn on shadow passwords, which are not used by default. Run
'pwconv' to move your passwords to /etc/shadow, where only root can
read them. Note that you'll have to update /etc/shadow by hand for
NIS users. See the pwconv(1M) and shadow(4) manpages.
- Limit the hosts from which portmap(1M) and rpcbind(1M) will accept
RPC requests by using the -a option in /etc/config/portmap.options.
For example, if your machine is www.xxx.yyy.zzz and your subnet is
www.xxx.yyy you can reject RPC requests from outside your subnet by
putting '-a 255.255.255.0 www.xxx.yyy.0' in that file. Despite the
file's name and the absence of any options in the rpcbind manpage,
this appears to work with rpcbind as well as portmap. Note also the
related putative bug under "security-related bugs" below.
This list is guaranteed to be incomplete. Keep your eyes open.
Similar lists are in SGI's security advisory 19950401-01-I, which is
at ftp://sgigate.sgi.com/Security/19950401-01-I, and a post by Dave
Olson <olson@sgi.com>, a copy of which is at
ftp://viz.tamu.edu/pub/sgi/software/security/olson-security.
------------------------------
Subject: -4- How can I log more information about logins?
Date: 27 May 1996 00:00:01 EST
- 'last', 'who', etc. get remote login information from
/var/adm/utmpx and /var/adm/wtmp. That information is only logged
into these files if they already exist. To create them, do
'touch /var/adm/utmpx /var/adm/wtmpx'. The analogous files under
IRIX 4.0.x are /etc/xutmp and /etc/xwtmp.
- If you're running IRIX 5.3, install patch 420 to fix a bug which
causes xterm(1) to log logins incorrectly.
- As described in the login(1) manpage, you can add the line
'syslog=all' to /etc/config/login.options (IRIX 4.0.x) or change the
line 'SYSLOG=FAIL' in /etc/default/login to 'SYSLOG=ALL' (IRIX 5.x)
to log all login attempts, not just successful ones, in
/var/adm/SYSLOG. Under IRIX 5.x only, the same change in
/etc/default/su has the same effect on 'su' attempts.
- 'ftpd', 'rshd', 'tftpd' and 'fingerd' all have options ('-l' or
'-L') which cause them to log all accesses. See their manpages.
'ftpd' also has '-ll' and '-lll' options (undocumented before IRIX
5.x) which log individual file transfers and the sizes of those
files respectively. Add the options to the last fields (not the
second-to-last) of the appropriate lines of /etc/inetd.conf, then do
'killall -HUP inetd' or reboot.
- Consider using Wietse Venema's tcp_wrappers, at
ftp://ftp.win.tue.nl/pub/security/. This allows you not only to log
most types of connections, but to restrict connections from
particular hosts and prevent some forms of address spoofing.
README.IRIX in current versions of tcp_wrappers describes a number
of ways in which it does not work well with IRIX, some of them
serious. tcp_wrappers is still useful, but read README.IRIX
carefully and test your configuration to be sure it's working.
------------------------------
Subject: -5- How can I make an anonymous or restricted FTP account?
Date: 13 Aug 1995 00:00:01 EST
Read the ftpd(1M) manpage and/or the article in the March/April 1994
Pipeline. However, both discussions have a serious error: the ftp
account's home directory (/usr/people/ftp) should be owned and
writable only by root, NOT ftp. You might also want to make the 'pub'
directory "sticky" with 'chmod +t' (like /tmp and /var/tmp) so that
one user can't delete another's files. Two scripts which set up a
secure or restricted anonymous FTP account are at
ftp://viz.tamu.edu/pub/sgi/software/ftp/.
------------------------------
Subject: -6- How can I get X authorization to work?
Date: 24 Feb 1996 00:00:01 EST
Under IRIX 5.1.x or earlier, don't try. The MIT-MAGIC-COOKIE-1
protocol did not work, and DGL programs did not understand X
authorization.
Under IRIX 5.2, heed the wise words of Mark Kilgard of SGI's
X Window Systems group <mjk@hoot.asd.sgi.com>:
The basic mechanism for the MIT-MAGIC-COOKIE-1 authorization protocol
is implemented by the X server, Xlib, and xdm, and does work in IRIX
5.x. MIT-MAGIC-COOKIE-1 is the only supported protocol.
Two caveats before I describe how to enable X authorization:
1) Old remote IRIS GL programs probably will not be able to connect to
the X server when X authorization is enabled. (More on this below.)
2) Due to a problem with how the local hostname is handled, to use X
authorization in the IRIX 5.x releases, you will need to make sure
your /etc/sys_id file has a simple hostname, ie. hoot instead of a
fully resolved hostname like hoot.asd.sgi.com This problem has
already been fixed for the next general release of IRIX.
TO ENABLE X AUTHORIZATION, do the following to your IRIX 5.2 system:
1) Edit /var/X11/xdm/xdm-config as root and change the line
saying
DisplayManager*authorize: off
to say
DisplayManager*authorize: on
2) Edit /var/X11/xdm/Xsession, /var/X11/xdm/Xsession-remote, and
/var/X11/xdm/Xsession.dt as root and change the line saying
/usr/bin/X11/xhost +
to say
#/usr/bin/X11/xhost +
This disables the "xhost +" by commenting out the command.
3) Make sure your /etc/sys_id file has no periods in it. For
example, change as root:
hoot.asd.sgi.com
to say
hoot
4) Reboot the machine OR restart a new xdm and X server. This
can be done as root with the following command:
(/usr/gfx/stopgfx; killall xdm; /usr/gfx/startgfx) &
5) Log in. X authorization should be enabled.
If you want to disable X authorization and return to the default
system state where X clients can connect to the X server from any
machine, reverse the changes in steps 1 and 2 and repeat step 4.
If you want more information on X authorization, see the manpages for
xdm(1), Xserver(1), Xsgi(1), Xsecurity(1), xauth(1) and xhost(1).
X AUTHORIZATION AND REMOTE IRIS GL PROGRAMS: One of the major reaons
for Silicon Graphics shipping its window system so that an X client
from any machine could connect to the X server was because IRIS GL
programs running remote using the DGL (distributed GL) protocol didn't
interoperate with the X authorization mechanism; the dgld daemon that
would run on the machine with graphics hardware had no way to get the
correct X authorization information to connect to the X server.
This has been fixed for IRIX 5.2, but the fix only applies to IRIX 5
binaries running remotely on an IRIX 5.2 system connecting to an IRIX
5.2 X server. In particular, remotely run IRIX 4 IRIS GL binaries
will continue to not interoperate with an IRIX 5.2 X server (or a
pre-IRIX 5.2 X server). If you recompile your old IRIS GL binaries
on IRIX 5.2, they then will work remotely connecting to IRIX 5.2 X
servers running X authorization.
The bottom line is that if you want an IRIS GL program to run
remotely on an X server using X authorization, you need to make sure
the program is an IRIX 5 binary running on an IRIX 5.2 machine and
the machine with the X server is also an IRIX 5.2 machine.
To avoid a possible misconception: IRIS GL programs RUNNING LOCALLY
(ie, not using DGL) WILL WORK FINE on an IRIX 5.2 system no matter if
they are IRIX 4 or IRIX 5 binaries. The problem with X authorization
is only for REMOTE IRIS GL programs.
Also note that for X authorization to work for remote hosts, the
remote program must have access to the correct X authorization magic
cookie (normally read from ~/.Xauthority). If you don't have a
shared NFS mounted home directory, you'll probably need to use the
xauth command to transfer the X authorization magic cookie to the
remote ~/.Xauthority file.
THE FUTURE: Hopefully in the next general release of IRIX, a
mechanism to enable and disable X authorization using a chkconfig
option will be supported. The problem with /etc/sys_id not having
periods will definitely be fixed in the next general release of
IRIX. The problem with pre-IRIX 5.2 X servers and binaries not
interoperating with X authorization will likely not be fixed. Fixing
the problem required a DGL protocol extension which both the IRIS GL
program and dgld must know about; this can't be fixed in already
shipped software.
Under IRIX 5.3, do what you did for IRIX 5.2. There is no chkconfig
option for X authorization. The problem with periods in hostnames is
still present in 5.3 as such, but is fixed by patch 518. There is a
bug in NFS3 which truncates ~/.Xauthority files which is fixed by
patch 216. See also the descriptions of the shared memory hole and the
putative X authorization weaknesses below under "security-related
bugs".
------------------------------
Subject: -7- What security-related bugs does IRIX have?
Date: 4 Jun 1997 00:00:01 EST
(Thanks to Yuri Volobuev <volobuev@t1.chem.umn.edu> for updating
several questions in this question.)
Some general comments before we start:
- IRIX is too complex for us to guarantee that this list is complete.
We only discuss problems we know about. We don't discuss insecurely
designed systems (like YP) or ways in which you might misconfigure
your system, only bugs. We don't discuss third-party software,
free or not.
- Prudence and space permit us to describe only how to close holes,
not to exploit them. Try comp.security.unix.
- Some of the fixes involve installing a new version of a setuid
binary. Be sure that you 1) make it executable, setuid and owned
by the correct user and group (or it won't work), and 2) remove the
old version so bad guys can't use it!
Now for the holes themselves:
- ftp://ftp.cert.org/pub/cert_advisories/CA-92:08.SGI.lp.vulnerability
describes problems with the permissions of 'lp'-related parts of
IRIX which allow anyone who can log in as lp to get root access.
They are fixed in IRIX 4.0.5. Briefly, the fix is
su root
cd /usr/lib
chmod a-s,go-w lpshut lpmove accept reject lpadmin
chmod go-ws lpsched vadmin/serial_ports vadmin/users vadmin/disks
cd /usr/bin
chmod a-s,go-w disable enable
chmod go-ws cancel lp lpstat
- ftp://ftp.cert.org/pub/cert_advisories/CA-93:17.xterm.logging.vulnerability
describes a hole in /usr/bin/X11/xterm which allows any user root
access. It is fixed in IRIX 5.x. A fixed version for 4.x is at
ftp://ftp.sgi.com/sgi/IRIX4.0/xterm/. The 'fix', incidentally, is
that logging is completely disabled.
- /usr/bin/under is an unused (!) part of 'rexd'. It is setuid root
and may allow root access, so 'chmod -s' it just in case. Note that
SGI ships IRIX with 'rexd' turned off because 'rexd' is itself a
security problem. It is not shipped in IRIX 5.x.
- ftp://ciac.llnl.gov/pub/ciac/bulletin/f-fy95/f-01.ciac-SGI-IRIX-serial-ports
describes a race condition in IRIX 4.0.x's
/usr/lib/vadmin/serial_ports which allows any user to become root
in IRIX 4.0.x. 'chmod 700' it to close the hole; it will still work
fine.
/usr/lib/vadmin/serial_ports is part of IRIX 4.0.x and should not
exist on IRIX 5.x systems, but some users have reported problems
with upgrading from 4.0.x to 5.x which leave old binaries behind.
If the file exists on your 5.x system, remove it. (5.x's
equivalent, /usr/Cadmin/bin/cports, does not have the problem.)
- /usr/bsd/rdist has several holes which allow any user root access in
all versions of IRIX before 5.3, including the 4.0.5 and 5.x
binaries on ftp.sgi.com.
Under IRIX 5.2, you can install patch 130 to close all known
holes. Under IRIX 4.0.x, you must close the hole with 'chmod -s'.
rdist will then work only when used by root. If your non-root users
need 'rdist', there is a free version, which does not need to be
setuid root and is thus free of all known holes, in
ftp://usc.edu/pub/rdist/. Make sure you get version 6.1 beta 3 or
later. IRIX 5.3's rdist is derived from this version and is thus
equally safe; presumably ordist is the IRIX 5.2-patch 130 rdist and
is also safe.
As for advisories, CERT advisory CA-91:20, at
ftp://ftp.cert.org/pub/cert_advisories/CA-91:20.rdist.vulnerability
is badly out of date, and
http://www.8lgm.org/advisories/[8lgm]-Advisory-1.UNIX.rdist.23-Apr-1991
and
http://www.8lgm.org/advisories/[8lgm]-Advisory-26.UNIX.rdist.20-3-1996.html
may not describe all of the known holes.
- The 'lpr' subsystem in every version of IRIX before 5.3 has several
holes which allow a non-root user to become root. Note that 'lp' is
SGI's usual printing system; you only need 'lpr' if you need to deal
with remote printers. If you don't need 'lpr', make sure it isn't
installed. (It lives in the eoe2.sw.lpr subsystem.) If you do need
'lpr', there are fixed versions at
ftp://ftp.sgi.com/sgi/IRIX4.0/lpr/lpr.latest.Z
ftp://ftp.sgi.com/sgi/IRIX5.0/lpr/lpr.latest.Z
The versions dated 29 and 26 April, respectively, work with NIS
(YP). The IRIX 5.x version is also available as patch 131.
- /usr/sbin/cdinstmgr is setuid root in IRIX 4.0.5[A-F] and
/etc/init.d/audio is setuid root in IRIX 5.2. They are scripts;
setuid scripts are a well-known Unix security problem. IRIX ignores
the setuid bit by default, but 'chmod -s' the scripts just in case.
- ftp://sgigate.sgi.com/Security/19950209-01-P describes a bug in
colorview in IRIX 5.x before 5.3, which allows anyone to use it to
read any file regardless of permissions, and gives a fix.
- /usr/bin/newgrp is group-writable in IRIX 5.2. It doesn't need to
be, and it might be a problem depending on your use of group sys
and/or the presence of the 'sadc' bug (described elsewhere in this
list) on your system. 'chmod g-w' it.
- /usr/sbin/printers has a bug in IRIX 5.2 (and possibly earlier 5.x
versions) which allows any user to become root. Apply patch 5. You
might want to 'chmod -s' it while you're waiting.
- /usr/sbin/sgihelp has a bug in IRIX 5.2 (and possibly earlier 5.x
versions) which allows any user to become root. This is so bad that
the patch (#65, along with the prerequisite patch 34) is FTPable
from ftp://ftp.sgi.com/security/, and SGI is preparing a CD
containing only that patch. Call the TAC if you can't FTP. You
should 'chmod -x /usr/sbin/sgihelp' while you're waiting.
- The inst which comes with patch 34 (for IRIX 5.2), which is required
for installation of all other patches (even those with lower
numbers) saves old versions of binaries in /var/inst/patchbase. It
does not remove execution or setuid permissions! 'chmod 700' that
directory so evil users can't get to the old binaries. The bug is
fixed in patch 82 for IRIX 5.2 and in IRIX 5.3.
- http://www.8lgm.org/advisories/[8lgm]-Advisory-11.UNIX.sadc.07-Jan-1992
describes a hole in the System V system activity reporting program
/usr/lib/sa/sadc which allows any user to write files with the
permissions of that program. This bug is present in all versions of
IRIX through 5.3, but since /usr/lib/sa/sadc is only setgid sys it
can only be used to change groups sys-writable files or write files
in group sys-writable directories. If you don't use the system
activity reporter you might want to 'chmod -s /usr/lib/sa/sadc' just
to be safe. Because this hole isn't serious it isn't scheduled to be
closed, but write permission for group sys has been removed from
most directories where it wasn't necessary in IRIX 5.3, and a few
more (/dev/*dsk) will be fixed in a later release.
- /usr/etc/mount_dos, IRIX's DOS-filesystem floppy mounter, has a
serious bug in IRIX 5.2 (and probably earlier releases of 5.x as
well) which allows anyone with an account on and physical access to
a machine with a floppy drive root access. This bug can be fixed
with patch 167 and is reportedly fixed in IRIX 5.3. Perhaps the
easiest interim "fix" (which essentially disables all removable
media drives) is to disable mediad: "mediad -k" kills the current
instance of mediad, and "chkconfig mediad off" prevents mediad from
starting during the next reboot.
- ftp://ftp.cert.org/pub/cert_advisories/CA-95%3A17.rpc.ypupdated.vul
describes a security hole which is present in /usr/etc/rpc.ypupdated
in all versions of IRIX. It is completely unnecessary in most
networks; the only instance that we could think of that might
require this daemon would be NIS networks that include Sun diskless
clients. You should probably comment it out of /etc/inetd.conf, or
just not install the nfs.sw.nis subsystem, of which it is a part. It
is commented out by default in IRIX 5.3.
- ftp://sgigate.sgi.com/Security/19950301-01-P373
describes a bug in /usr/lib/desktop/permissions in IRIX 5.2, 6.0 and
6.0.1 which allows any user to change the permissions of any file to
anything. (Click on "Apply" twice fast, then click "Cancel" to
dismiss the root password window.) It is fixed in patch 373 for IRIX
5.2, 6.0 and 6.0.1 and in IRIX 5.3. Until you patch or upgrade,
'chmod -s' it to close the hole.
- sendmail is a complex program in which new security holes are
discovered almost daily. Some of these holes enable unprivileged
users (and in one case even *remote* users!) to gain root access.
The safest course of action seems to be to use the most recent
sendmail possible.
Recent sendmail patches also fix a bug present in every IRIX
sendmail before 5.3: /usr/bsd/newaliases (which is just a symlink to
/usr/lib/sendmail) creates /etc/aliases.{dir,pag} with mode 666. Any
user can thus add aliases which can run programs or steal mail.
Close the hole with 'chmod go-w /etc/aliases.dir /etc/aliases.pag'.
sendmail doesn't change those files' permissions once they exist, so
a) you should check them even if you've installed a sendmail in
which the problem is fixed and b) once they exist and have proper
permissions, you're OK.
- /usr/etc/arp has a hole in IRIX 5.2 and earlier which allows any
user to read files with 'arp's permissions, i.e. group sys. Close
the hole with 'chmod -s'. This prevents non-root users from using
'arp' at all, but they don't generally need it. The hole is closed
in IRIX 5.3.
- SoftWindows 1.25 (which is distributed by SGI in Desktop Support
Environment 1.0 and HotMix 11) includes an installation script which
executes Netscape as root. This can be used to gain root access,
etc. Patch 905 (if your Softwindows is installed as the
"SoftWindows" subsystem) or 908 (if it's in the "swin" subsystem)
fixes the script.
- ftp://ftp.cert.org/pub/cert_advisories/CA-95:14.Telnetd_Environment_Vulnerability
describes a vulnerability in telnetd which is present in IRIX before
6.2. A remote user can use telnet/telnetd to pass environment
variables to login which cause login to use an arbitrary shared
library. If the same user can place a shared library on the system
running telnetd (e.g. by depositing it in an incoming FTP
directory), that user can gain root permissions. There is a related
hole in login(1): it allows one to set LD_ envariables from the
command line, and, if they are already present in its environment,
passes them
--
※ 来源: 中国科大BBS站 [bbs.ustc.edu.cn]