SRB-2006-0003

A user from a remote SRB client with write permissions on an SRB server can read, write, and delete the same set of files on the SRB server as the srb operating system user (the user id that runs the SRB server). Any file, including SRB objects, scripts, logs, and configuration files, may be compromised. Additionally, other sensitive system files may be read, such as /etc/passwd, that may aid in other attacks. This is the case even if checks for non-sysadmin SRB user types are functioning.

SRB user with write permissions

This vulnerability requires a user to be able to connect and authenticate to an SRB server, and the user must have write access to a single SRB collection and resource to be able to access files on the SRB location containing the resource.

low

To exploit this vulnerability requires only the execution of S-commands.

medium

The user can read, write, and delete arbitrary operating system files on the SRB server from a remote client, as if they were running as the user that the SRB software runs. Depending on how the software is installed, this could allow the reading and writing of the configuration files, scripts, and logs of the SRB system.

It can also allow the reading, and possibly writing, of sensitive files or secret information. This includes files such as /etc/passwd, database passwords, restricted SRB object files, SRB server passwords, and encryption certificates. Reading or updating these types of files may aid in other attacks.

The SRB system allows a user to add a name to an SRB collection where the contents of the object is actually an existing file on the SRB server. This is done using the client API or the Sregister command. Any SRB commands that access the SRB object now access the contents of the existing file. The file must exist to write to it, because the commands to update a file will not create the file.

If the vulnerability in SRB-2006-0001 and SRB-2006-0002 are fixed and authorization checks are properly made, there is still a vulnerability in registering objects in the SRB. The code checks to make sure that a non-sysadmin user type can only register files that are within the user's directory in the resource's storage directory (storage vault). If the resource's physical storage directory is $resourceVaultDir, then for user, $user, in the domain, $domain, the user should be restricted to registering files contained in the directory tree, $resourceVaultDir/$user.$domain/.

The code checks that the textual prefix of the path matches the resources vault directory. It does not check to see if the user has crafted a file path that contains parent directory components. This allows the user to create a file path with the proper directory prefix and then as many parent directory components as needed to escape out of the vault, and finally the path to the file the attacker wishes to access. If the resources vault directory is /vaults/resource1 then a path of /vaults/resource1/user.domain would be the users directory in the vault and /vaults/resource1/user.domain/../../.. would be a reference to the root of the file system, and would also pass the containment check.

In the examples below, let the value $usersDirPrefixedRoot represent $resourceDir/$user.$domain/../../.., with the same number of parent directory components (or more) than the directory level of the user's directory.

For instance, to read the /etc/passwd file on an SRB server (location) containing the default resource, the following series of commands can be used:

    Sinit
    Sregister $usersDirPrefixedRoot/etc/passwd
    Scat passwd
    Sexit
  

If ssh access to an SRB server host is allowed and ssh identities are used, then ~/.ssh/authorized_keys2 files exists, and the following series of commands can be used to allow a user to login as the srb user on the SRB server:

    Sinit
    Sregister $usersDirPrefixedRoot//home/srb/.ssh/authorized_keys2 sshKeys
    Sappend ~/.ssh/id_dsa.pub sshKeys
    Sexit
    ssh $srbServerHost
    # enter the password of the ssh identity if it has one
  

If it can be determined that the log directory of the SRB server is $logDir, then the following series of commands can be used to delete the log file from May 10th, 2006:

    Sinit
    Sregister $usersDirPrefixedRoot/$logDir/srbLog.5.10.6 theLog
    Srm theLog
    Srmtrash
    Sexit
  

To modify a restricted SRB object that has is stored at the operating system path of $osPathToSrbObj, obtained with Sls -p $srbObj, the following series of commands can be used:

    Sinit
    Sls -p $srbObj
    Sregister $osPathToSrbObj myObj
    Sput newContents  myObj
    Sexit
  

directory traversal

When a path is registered, the path is not canonicalized so it may contain path components that are parent directory entries. This allows an attacker to create a path that passes the simple check for containment within the resources vault directory.

Paths to files should be canonicalized before checking for containment, or at least the path to the file supplied by the user should not be allowed to contain components that refer to a parent directory (..).

A check was inserted into the matchVault() function to check for "/../" within the file path supplied by the user. This prevents access to directories outside of the users subdirectory tree, unless there are symlinks allowing this traversal contained within the users directory tree, which should not occur.

This research funded in part by the National Science Foundation under contract with San Diego Supercomputing Center and National Science Foundation grant CNS-0627501.