Bug 3367 - Security Issues in MDS4 Aggregator Services
: Security Issues in MDS4 Aggregator Services
Status: RESOLVED FIXED
: MDS4
general
: development
: PC Linux
: P3 critical
: ---
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2005-05-17 00:52 by
Modified: 2005-05-18 13:51 (History)


Attachments
Security advisory (2.58 KB, text/plain)
2005-05-17 00:54, Laura Pearlman
Details
Patch installation instructions (3.86 KB, text/html)
2005-05-17 00:55, Laura Pearlman
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-05-17 00:52:27
Please read the attached advisory for a description of the problem and patch
installation instructions for the solution.
------- Comment #1 From 2005-05-17 00:54:20 -------
Created an attachment (id=612) [details]
Security advisory
------- Comment #2 From 2005-05-17 00:55:27 -------
Created an attachment (id=613) [details]
Patch installation instructions
------- Comment #3 From 2005-05-17 18:33:23 -------
Text of security advisory:

Globus Project(tm) Security Advisory 2005-02:  MDS4 Index and Trigger Service
Vulnerability


Original issue date: May 17, 2005
Last revised: None

Software effected:

Globus Toolkit, releases 3.9.x and 4.0.0

Specific package: WS MDS

Overview

The WS MDS Index and Trigger services contain vulnerabilities that can be
exploited by remote users to run programs on the server.  The WS MDS Index
and Trigger services are deployed by default in GT 3.9.x and 4.0.0
installations, so we recommend that everyone running these versions of the
toolkit apply the patch referred to below.

I. Description

The WS MDS Index and Trigger services gather data through the use of
several modules which collect and format data which will then be used
by the MDS services.  One of these modules, the Aggregator Execution
Source, runs a script to collect data: system administrators make
scripts available for use by putting those scripts in the directory
$GLOBUS_LOCATION/libexec/aggrexec; users can then specify which of
those scripts to run.  However, because of a coding error, a malicious
user can specify a script located anywhere on the server, not just in
the administrator-controlled $GLOBUS_LOCATION/libexec/aggrexec directory.

The WS MDS Trigger service executes scripts when certain conditions
are met.  Administrators make scripts available for use by putting
those scripts in the $GLOBUS_LOCATION/libexec/trigger directory; users
can then specify which of those scripts to run under what conditions.
Because of a coding error, a malicious user can specify a script
located anywhere on the server, not just in the
administrator-controlled $GLOBUS_LOCATION/libexec/trigger directory.

II. Impact

The bug allows malicious users to run programs on the server as the globus
user.

III. Solution

An update package with a fix for Globus Toolkit (R) 4.0.0 is available at:

http://www-unix.globus.org/toolkit/advisories.html

This update changes the mechanism by which scripts are made available
by administrators.  In the new mechanism, administrators who wish to
make scripts available for execution by the Index or Trigger service
must assign each script a logical name, and enter a mapping from the
script's logical name to physical location in the (Index or Trigger)
service's jndi-config.xml.  Users now specify these logical names
instead of the script file names; if no mapping exists for a logical
name, a warning is logged and nothing is executed.  A similar mapping
is used for scripts executed by the Trigger service.

We recommend that people running 4.0.0 apply this patch and that
people running 3.9.x upgrade to 4.0.0 and apply the patch.
------- Comment #4 From 2005-05-17 18:34:53 -------
Text of installation instructions (these also appear, in a somewhat more
readable form, in the attachment above):

Applying the patch

Important note: installing this patch currently overwrites all configuration
files for the affected components with the default versions of those files, so
any changes to such files should be backed-up before applying the patch. This
includes the service descriptor (.wsdd) files and the contents of the service's
"etc" directory. Specifically, consider backing up the following files if you
have made modifications to them:

    * $GLOBUS_LOCATION/etc/globus_wsrf_mds_index/hierarchy.xml
    * $GLOBUS_LOCATION/etc/globus_wsrf_mds_index/upstream.xml
    * $GLOBUS_LOCATION/etc/globus_wsrf_mds_index/downstream.xml

To apply this patch, choose one of the following two methods:

   1. Download the GPT version of the patch and run:

    gpt-build -update gt4.0.0-wsmds-security-update-bundle.tar.gz

   2. Or download the GAR version of the patch, untar it into an empty
directory, and run:

    globus-deploy-gar globus_wsrf_mds_aggregator.gar
    globus-deploy-gar globus_wsrf_mds_index.gar
    globus-deploy-gar globus_wsrf_mds_trigger.gar

What the patch does

The patch causes services (such as the Index and Trigger services) that execute
scripts to require that the administrator to establish a logical-to-physical
filename mapping for executing scripts. The logical-to-physical mapping for
scripts used by the Execution Aggregator Source to collect information is
established by specifying a list of comma-delimited name-value pair entries for
the executableMappings parameter of the AggregatorConfiguration entry in the
JNDI configuration file for the Index and Trigger Services
($GLOBUS_LOCATION/etc/globus_wsrf_mds_{index,trigger}/jndi-config.xml). The name
is a logical name that will be used to refer to the script; the value is the
path to the script, relative to the $GLOBUS_LOCATION/libexec/aggrexec directory.

Similarly, the patch causes the trigger service to require the administrator to
establish a logical-to-physical mapping for executing trigger scripts (the
scripts that are executed when trigger conditions are met). This mapping is
established by specifying a list of comma-delimited name-value pair entries for
the executableMappings parameter of the triggerConfiguration entry in the
Trigger service's JNDI configuration file. The name is a logical name that will
be used to refer to the script; the value is the path to the script, relative to
the $GLOBUS_LOCATION/libexec/trigger directory.
An example

Below is an example of the "executableMappings" parameter from the Index Service
jndi-config.xml file:

<resource name="configuration"
type="org.globus.mds.aggregator.impl.AggregatorConfiguration">
 <resourceParams>
  ...
  <parameter>
   <name>executableMappings</name>
    <value>aggr-test=aggregator-exec-test.sh, pingexec=example-ping-exec</value>
  </parameter>
 </resourceParams>
</resource>

The name in this example is "aggr-test". This is the logical name of the
user-specified probeName or trigger actionScript parameter. The value, in this
case "aggregator-exec-test.sh", is the real name of the executable file. Only
files which map correctly to the supplied logical name can be executed by remote
users.
Regarding unit tests

Please also note that the unit tests for the above modules are not included in
the current iteration of the patch, though an updated version of the tests are
required (for the Index and Trigger services) should you want to run the unit
test against a patched 4.0.0 install. These updated tests are currently
available in the CVS repository and will be included in the 4.0.1 point release.
------- Comment #5 From 2005-05-18 13:51:49 -------
The name of the patch bundle is actually
wsmds-security-update-bundle-4.0.0.tar.gz, not
4.0.0-wsmds-security-update-bundle.tar.gz.