--VbJkn9YxBvnuCH5J
Content-Type: text/plain; charset=us-ascii
This is to inform you of a security vulnerability in Cabletron
Spectrum Enterprise Manager. (For the unfamiliar, "Spectrum" is a high-
end Network Management System.) Among other things, this vulnerability
allows non-root shell users, on the machine on which the server product
is installed, to be able to obtain "root" privilege. This vulnerability
exists in, at least, version 5.0.1 (the current version as of this
writing) under Solaris.
PROBLEM
The Spectrum Enterprise Manager installation process creates a directory
tree in which most directories and many files allow write permission for
"other" (and "group") users. (This is done regardless of the umask in
effect at the time of the install - i.e. it is not able to be influenced
easily by the installer.) The writable directories include those
containing the Spectrum executables, at least one of which is, and
apparently must be, run as "root" during normal operation of the product.
I have determined that this directory permissions situation can be
exploited by an unprivileged shell user (on the Spectrum server machine
where the product is installed) to cause a component of Spectrum to run
any executable, of the user's choosing, as "root".
No doubt, there are other implications to these directories and files
being able to be modified by "other". For instance, a trojan horse
could be installed in place of a normal component executable or script,
or the Spectrum installation could be made dysfunctional by the removal
of the contents of the writable directories by an unprivileged user.
At the very least, either of these could amount to a Denial-Of-Service
attack on the Spectrum services hosted on the server machine.
I have not determined whether a similar vulnerability exists when
Spectrum is installed under NT, nor whether these vulnerabilities affect
SpectroGRAPH (client-only) installations. My guess is that SpectroGRAPH
client machines would be similarly vulnerable to the unprivileged users
being able to unlink directory entries or modify various files. However,
those client installations are unlikely to be vulnerable to unprivileged
users by allowing them to obtain root access, since I know of no
SpectroGRAPH components which runs as root. Other user accounts might be
able to be compromised by virtue of the permissions facilitating the
installation of a trojan horse.
SOLUTION
In April I reported this problem to Cabletron and have an as yet
unresolved case open (case #267248, escalated #17974) with their Global
Technical Assistance Center.
Hopefully a patch will be made available and corresponding changes so
future releases, upgrades, and patches will not re-introduce this
vulnerability.
The latest information I have is that the fix is slated for "CS3/MMS3"
(the 3rd Core Supplement/Management Module Supplement), for which a
release date has not been set. As of this writing, "CS2/MMS2" has yet
to be released, so Spectrum customers may be waiting some time for a
vendor-supplied solution. I've heard that they intend to release such
supplements quarterly but only CS1/MMS1 has been released so far.
In the mean time, here's two alternative potential solutions:
1) Do not create, or allow login for, *any* user accounts on the Spectrum
host other than for those users who normally use Spectrum and whom you
trust not to damage your Spectrum installation. Also, beware of
offering services such as anonymous ftp on that host since such
services could allow the overwriting of files in the Spectrum directory
hierarchy.
- OR -
2) Tighten up the permissions for the Spectrum directory hierarchy.
(See the example "secure_spectrum" script.)
We can make use of the group permissions to increase security, while
still allowing multiple SpectroGRAPH users to write into various
Spectrum directories, as is apparently necessary:
When setting up Spectrum Enterprise Manager, create a "spectrum" group.
Make this "spectrum" group the group for the $SPECROOT directory and all
sub-directories and files underneath. Then turn on the set-gid bit of
$SPECROOT and all sub-directories so that subseqently-created sub-
directory entries will "inherit" that group id, i.e. "spectrum".
(Without the set-group-id bit, these entries would have had their group
set to the effective group ID of the creating process.) If you have
the opportunity to do this before installing Spectrum, that is ideal.
A umask of 02 (i.e. allow user and group write permission) when for the
users in the "spectrum" group might be useful as well. (This can be set
up in the individual users ".profile".)
When seting up Spectrum user accounts, place only the Spectrum install
"target user" (usually called "spectrum") and those users who should be
allowed to run SpectroGRAPH on this server into the "spectrum" group so
that only this subset of users will have write access to the Spectrum
directories and files that allow write permission for the group. I
suggest that the "SDPM" directory, and any directories and files that
should not be modified during the normal operation of Spectrum, should
disallow group write permission as well.
I have provided a script called "secure_spectrum" as an example to help
a Spectrum administrator configure Spectrum as just described.
After installing Spectrum and any subsequent upgrades or patches, run
this script:
# export SPECROOT=/my/spectrum/dir
# ./secure_spectrum
Even with this proposed solution, there are outstanding issues:
* There are still a number of files that Spectrum creates (primarily
log files) that allow write permission by others.
* Users in the "spectrum" group can still do destructive things, such
as removing necessary files under the Spectrum directories. I see no
easy way to avoid this since Spectrum doesn't clearly define which
directories should be read-only and which should be allowed to be
modified during normal use... Some directories, such as "SS" and
"SS/DDM", even contain both executables *and* modifiable database
files.
Also, until the vendor addresses this issue, remember that subseqent
upgrades and patches could reintroduce the vulnerability by extracting
new files with the lax permissions. Be sure to check for this and,
if necessary, re-apply more restrictive permissions afterward.
DISCLAIMER
Use my suggestion (outlined above) at your own risk... It would be a
Good Thing(tm) to backup your spectrum installation prior to any such
experimentation. IMO, it does eliminate aforementioned vulnerabilities,
but may introduce unexpected problems since I know not if components of
Spectrum have accidentally come to rely upon the more "permissive"
directory structure. Spectrum development folks would best be able to
fully ascertain the side-effects.
--
plonkaat_private http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI
--VbJkn9YxBvnuCH5J
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=secure_spectrum
#! /bin/ksh
# secure_spectrum - a script to shore up security on a Spectrum 5.0r1 install.
# $Id: secure_spectrum,v 1.1 1999/06/23 21:02:52 plonka Exp $
# Dave Plonka <plonkaat_private>, Jun 23 1999
# Check Cabletron GTAC case #267248, escalated #17974 for details on the
# security issues that this script is attempting to correct.
# A description was supplied in the file "Spectrum_bugtraq.txt" distributed
# with this script.
# I suggest running this script after installing Spectrum, applying patches,
# or applying core or management module supplements.
# This has been tested before and after the application of CS1/MMS1.
# configuration - target user and group:
typeset target_user=spectrum
typeset target_group=spectrum
# external commands used by this script:
find=/usr/bin/find
xargs=/usr/bin/xargs
chown=/usr/bin/chown
chmod=/usr/bin/chmod
if cd ${SPECROOT?}
then
:
else
print -u2 "Could not change to \$SPECROOT directory: ${SPECROOT?}"
exit 1
fi
# set owner and group of directories and non-setuid files:
${find?} . \( -type d -o \( -type f ! -perm -4000 \) \) -print |${xargs?} ${chown?} ${target_user?}:${target_group?}
# turn on set-gid and remove write permission for others on directories:
${find?} . -type d -print |${xargs?} ${chmod?} g+s,o-w
# remove write permission for others on files:
${find?} . -type f -print |${xargs?} ${chmod?} o-w
# remove write permission for group and other on set-uid files:
${find?} . -type f -perm -4000 -print |${xargs?} ${chmod?} g-w
# remove write permission for group on SDPM directory (where processd resides):
${chmod?} g-w SDPM
exit 0
--VbJkn9YxBvnuCH5J--
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:50:47 PDT