SRB-2006-0002

A user with the ability to register files on the SRB server can subvert the access control mechanism to read, modify, and delete arbitrary SRB objects stored in an operating system file system on the SRB server.

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. The attacker must also be able to determine the full path to the operating system file used to store the SRB object.

low

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

medium

The user can read, modify, and delete existing SRB objects that they would not normally be able to access. This can reveal secret information and also compromise the integrity of data in the SRB system.

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 SRB server will not allow the registering of the exact same path twice in the system, but file paths are not canonicalized before the check is made, so the same file can be specified using paths that resolve to the same file. /d1/d2/file, //d1/d2/file, /d1/./d2/file, and /d1/../d1/d2/file are all paths that specify the same file. There are even more ways to create a path specifying the same file if hard and symbolic links are taken into account.

The SRB object that the user registers is owned by the registering user, therefore, the user can read, modify and delete the object with the underlying file being modified.

There is no access control mechanism for who is allowed and what files or directory trees a user is allowed to register into the SRB space. The only difficulty is that the user needs to be able to get the full physical operating system path to the SRB object they want to register twice. This is easy to get if the user has read access to the SRB collection containing the object using the 'Sls -p srbPath' command.

For instance, if there is an SRB object that has the SRB path of $srbObj to which the user has insufficient access granted, and that object has an operating system path of $osPathToSrbObj, then the following series of commands can be used to subvert the SRB permission system

To read the file, the following series of commands can be used:

    Sinit
    Sls -p $srbObj
    Sregister $osPathToSrbObj myObj
    Scat myObj
    Sexit
  

To modify the file, the following series of commands can be used:

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

To delete the file, the following series of commands can be used:

    Sinit
    Sls -p $srbObj
    Sregister $osPathToSrbObj myObj
    Srm myObj
    Srmtrash
    Sexit
  

logic error
ambiguous data representation
incorrect authorization

When a path is registered, the path is not canonicalized so it is impossible to tell if the path has already been registered in the system as each file in the file system has essentially an infinite number of path representations. Also, there is no access control mechanism for who is allowed and what files or directory trees a user is allowed to register into the SRB space. The ability to do this does not require extraordinary privileges, so users with a simple write privilege anywhere can exploit this vulnerability.

There is code that will perform an authorization check when a user registers a file to require that the file system file must be within the users home directory tree in a resources storage vault. This check is controlled by a server run-time environment variable ALLOW_NON_CHECKING_REGISTERY_OF_DATA. If the variable is not defined, the default, then the check is made unless the user is a sysadmin type, otherwise no authorizations check is made. The logic for the check is reversed in the case of registering data, so the default of not defining the variable, causes no authorization check to be made.

File paths should be canonicalized before being passed to the function, check_unique_dname_in_respath, and used in the registration process. This means that the resulting path to the file should contain no empty path components, no same directory components ('.' or empty), no parent directory components ('..'), and no symbolic links. The use of the POSIX call realpath() or something similar would perform this task.

A simple short term fix would be to require an SRB user to be an administrator in order to register a file in the SRB space using the Sregister command or the client API. This would at least restrict this operation to users that are designated as administrators, which are presumable trusted.

A better solution would be to have a mechanism that can specify what permissions a user has to have to register a location in the local file system into the SRB space. The access control system should disallow the registering of any path contained within a resource's storage directory.

Fixing the logic bug in the use of the run-time environment variable ALLOW_NON_CHECKING_REGISTERY_OF_DATA restricts unchecked registration of files to sysadmin user types. Other users can only register operating system files that are within their directory in the storage vault for a resource. Presumable all files within their directory in the storage vault are owned by the users, so attacks on other user's files are prevented.

This vulnerability still exists if the ALLOW_NON_CHECKING_REGISTERY_OF_DATA environment is set for the srbServer, or if files owned by another user can somehow end up within a users storage directory in a resources vault. Also users will be able to perform this attack on their own files and by deleting one of them can end up with dangling SRB objects, that may result in other problems.

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