Globus security advisory 2008-07: Code injection via world-writable RPATHs

Summary

Some Globus binary installers contain executables and shared libraries with RPATHs that may be world-writable directories, which could lead to code injection.

Relevant Versions

This advisory affects the following Globus Toolkit versions:

All 4.0.x versions of the Globus Toolkit, 4.0.7 and earlier.

Date Announced

2008-06-09

Description

Many executables and shared libraries contain an RPATH, which is a hard-coded list of directories that may contain shared libraries needed by the application. An RPATH is similar to a better known mechanism called LD_LIBRARY_PATH, but the RPATH is hard-coded into the executable (not the code, but the executable's header), unlike the LD_LIBRARY_PATH which is set by users. RPATH also takes precedence over LD_LIBRARY_PATH.

Note that RPATH is specific to ELF binaries, which are the default on Linux and Solaris, though other executable formats may contain a similar feature.

Due to a side effect of how Globus binaries are built, the RPATH will often contain directories beginning with /home/condor/execute For example, for one particular platform, you can see the RPATH for myproxy-init:

> objdump -p myproxy-init | grep RPATH
  RPATH       /home/condor/execute/dir_15763/userdir/install/lib

The security vulnerability arises from the fact that /home/condor/execute is a common location to store Condor's execute directory, and Condor's execute directory is normally world-writable. So if /home/condor/execute exists, and if it is world-writable, then any local user can easily inject code into many Globus binaries by placing specially constructed shared libaries there.

The attack relies on the fact that one element of the RPATH is world-writable. If you do not have a /home/condor/execute directory, or if you do but none of those directories is world-writable, then your site is not at risk.

The other way your site could be at risk is if you built from source into a world-writeable location such as /tmp.

Solution

If you do not have a /home/condor/execute directory on your system (on any computer where the Toolkit is installed, including computers that access the Toolkit through mounting a shared filesystem), then you do not need to apply any fix because there is no vulnerability.

If you do have a /home/condor/execute directory, and if any of those directories (/home, /home/condor, or /home/condor/execute) is world-writable, then there are three possible remedies for you:

Option 1: Install from source

Installing from source will build in RPATHs that are equal to your installation directory.

Option 2: Modify your system

Remove the offending directory, /home/condor/execute. If you use Condor, you can tell Condor to use a different execute directory. Naming it anything else will be fine, perhaps /home/condor/EXECUTE.

Option 3: Upgrade to Condor 7.0.2 or later

Condor 7.0.2 does not require the execute directory to be world-writable, as long as the execute directory is not on NFS. Therefore upgrading to Condor 7.0.2 or later will remedy the problem for you. Note that Condor should automatically restrict the permissions on the execute directory if they are world-writable, so you shouldn't need to modify them manually.

Questions

Please contact gt-user@globus.org if you have any questions.