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: plonkaat_private [mailto:plonkaat_private] Sent: Wednesday, June 23, 1999 2:17 PM To: spectrumat_private; bugtraqat_private 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. -- plonkaat_private http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:50:44 PDT