SRB-2006-0001

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). The user can not access data in a collection but can access all other files that the srb user can access. Any file, including 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.

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, 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.

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 there is no way to list the contents of the file system, so the full path to the file must be known before the register command can occur. However, many files are in well-known locations or some simple guessing can be used to arrive at the correct file path.

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 /etc/passwd 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 /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 $logDir/srbLog.5.10.6 theLog
    Srm theLog
    Srmtrash
    Sexit
  

logic error
lack of authorization

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. Also, 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.

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. This would create a white list of users and locations in the file system, so only approved users could register approved locations in the file system into the SRB space.

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. The only way for a file to be within this directory tree would be through the SRB (which can not be registered with this vulnerability), or if an operating system administrator specifically places files in this directory tree (presumably this is done for the purpose of registering the files).

This vulnerability still exists if the ALLOW_NON_CHECKING_REGISTERY_OF_DATA environment is set for the srbServer, or if non-SRB files can somehow end up within a users storage directory in a resource vault.

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