[10893] in bugtraq
Re: Cabletron Spectrum security vulnerability
daemon@ATHENA.MIT.EDU (Miscioscia, George M)
Thu Jun 24 13:13:18 1999
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <7DF40C8D8893D21184940008C709AAFC16560D@corp-exc4.ctron.com>
Date: Thu, 24 Jun 1999 00:24:00 -0400
Reply-To: "Miscioscia, George M" <georgem@CABLETRON.COM>
From: "Miscioscia, George M" <georgem@CABLETRON.COM>
X-To: "plonka@doit.wisc.edu" <plonka@doit.wisc.edu>,
spectrum@po.cwru.edu
To: BUGTRAQ@NETSPACE.ORG
Spectrum users,
This statement is not entirely true...
"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."
Although certain directories are made writable, the SpectroSERVER executable
need only run once as "root". It is a suggested practice to create your
Spectrum "Administrators" and "Operators" during this initial running. Once
done, shut down the SpectroSERVER and then restart it as a Spectrum
"Administrator". Open the User Editor and destroy the "root" user
immediately. There is no need for its presence anymore. The same holds
true for Windows NT, destroy the "Administrator" model from the
SpectroSERVER database.
I was told once by a wise man that there is no such thing as computer
security. The only thing that you can do is try to make it as difficult as
possible for someone to gain access. The only true way to secure a computer
is to shut it off and lock it in a closet.
-----Original Message-----
From: plonka@doit.wisc.edu [mailto:plonka@doit.wisc.edu]
Sent: Wednesday, June 23, 1999 2:17 PM
To: spectrum@po.cwru.edu; bugtraq@netspace.org
Subject: Cabletron Spectrum security vulnerability
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.
--
plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison,
WI
