Bug 4648 - grid-proxy-init proxy credentials race condition
: grid-proxy-init proxy credentials race condition
: Java WS Security
: 4.0.2
: PC Windows XP
: P3 normal
: 4.0.3
Assigned To:
  Show dependency treegraph
Reported: 2006-08-08 09:01 by
Modified: 2008-01-11 15:56 (History)



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

Description From 2006-08-08 09:01:22
The following is being provided with permission for unlimited distribution.

We encourage you to apply the provided patch, or similar fixes, to the
distributed source and announce this vulnerability to at-risk organizations and
the general public via at least one public mailing list designed for these
purposes (such as bugtraq@securityfocus.com or
full-disclosure@lists.grok.org.uk).  We ask that you provide a discovery credit
in any advisories or announcements.

Please reply with any questions or comments, and keep us informed of response


Vulnerable:  Globus Toolkit's grid-proxy-init
Version:     GT 4.0.2, GT 4.1.0, maybe others

Effect:      Ordinary users can obtain X.509 certificate and private key
             of arbitrary users that use grid-proxy-init to generate
             a proxy credentials file.

Discovery:   Benjamin Bennett, Pittsburgh Supercomputing Center

  grid-proxy-init is used to create X.509 proxy credentials and store these
credentials for future use.  By default, these credentials are stored in /tmp
with a well known filename based on uid number. Attempts are made to ensure
that this location is safe before writing credential data.

  A race condition exists between the opening of the proxy credentials file,
and making sure it is a somewhat safe file to write to.  The file is opened for
writing during a call to the SSL library's BIO_new_file function.  The checks
to ensure safety of this file take place using the filename _after_ the file is
opened for writing, but before any data is written.

  An attacker thus has the time between the open and the checks to remove or
change the proxy credentials file's directory entry.
  The open could take place on a file or device the attacker can read, and the
checks could take place on a different file or device, or even one the victim
creates during these checks.  Assuming the checks succeeded, proxy credential
data will then be written to the file or device the attacker can read.

  Typically there is a very short amount of time between the open and the
checks being performed making this situation fairly difficult to exploit.

  Since the call to BIO_new_file causes the credentials file to be opened
write-only, the provided exploit creates a FIFO, and a symlink to this FIFO at
the victim's proxy credentials file location.  This causes the victim's open to
block until another process opens the FIFO for reading, giving us as much time
as we need between the open and the checks.

  Once the victim's open is blocked, the exploit removes the symlink.

  The exploit then opens the FIFO for reading, causing the victim's open to
return, the victim's checks create a new file in the proxy credentials file
location and make sure it is safe.  Following those checks, the certificates
and private key are written out to the FIFO which the exploit is reading from.

  Ideally, the proxy credentials file location would be unlinked (if it
exists), opened using O_CREAT, O_EXCL, the following checks would use the file
descriptor return by the open, and that file descriptor would be handed off to
SSL libs via BIO_new_fd.  The provided patch does _not_ do this, as it requires
changes to both gsi/credential and gsi/sysconfig portions and may break other
portions of the code.

  The provided patch simply performs the checks _before_ that location is
opened for writing.  This should be adequate to prevent the exploitation paths
that I can think of.
------- Comment #1 From 2006-08-08 09:07:21 -------
Summary of Java side fixes: 

A utility method has been added to CoG (org.globus.util.Util::createFile), that
can be used to "securely" create a file. That method checks if file already
exists, if so tries to delete it and create again. If either deletion of old
file or creation of new one fails for any reason, an exception is thrown.

The "Util.setPermissions(fileName, 600)" method has been encapsulated into a
separate method, setOwnerAccessOnly(fileName).

All files created in GSI code in CoG and the Java WS Security code has been
updated to use the above utility to create file and set permissions before
anything is written to the file. These fixes have been pushed to trunk, 4.0
branch and community branch.

No solution has been found to atomically create a file and set relevant
permissions as yet. The current plan is to add a note about it in the advisory
and ask folks to use a umask that would restrict access created to the file.
------- Comment #2 From 2006-08-08 16:20:19 -------
The patch has been committed to trunk, 4_0_branch, 4_0_community and 3_2_branch