CONDOR-2006-0006

The use of FS or FS_REMOTE authentication methods can result in a spoofing of identity if an attacker has access to the file system used to perform the authentication.

local ordinary user

This vulnerability requires local access on a machine that allows running a condor_schedd or another Condor daemon, to which the user can use condor_submit or another Condor command that talks to a daemon.

medium

To exploit this vulnerability requires a modified Condor user command that will subvert the FS and FS_REMOTE authentication algorithms.

high

Since the user can spoof the identity of any user in the system except root, they can become any user and access any resources that are available to that user. This includes the account used to run the condor components, that can then be used to disrupt operation of the Condor pool, including denial of service attacks and the integrity of existing jobs in the system.

The FS and FS_REMOTE authentication methods depend upon the authenticating party being able to produce a file with a name given by the service requiring authentication. The location of the file for the FS method is in the /tmp directory, and in the case of FS_REMOTE, it would be in a directory that is writable by a group or all users and is on a networked file system.

The problem is that the authentication algorithm depends on the ability to create a file in the directory that has the following attributes: owned by the authenticating user, is not a symbolic link, and has a link count of one (no hard links). Unfortunately, there are several ways that a user can arrange to have a file with an arbitrary name appear in a directory to which they have write access.

The first way is when the directory is writable by the attacker, the directory does not have a sticky bit set (or the file system does not support the sticky bit behavior on directories, only the owner/root can rename or remove directory entries), and there exists a file owned by the spoofed user on the same file system that is also in a directory that is writable by the attacker. In this case, the attacker can simply move the existing file to the desired name and after the authentication passes, the file can be moved back.

The second way, which works even in a directory that has the sticky bit set, requires that the directory is writable by the attacker and that spoofed user had created and deleted a file on the file system prior to the attack. The prerequisites for this attack are commonly found in the /tmp directory on most UNIX systems. The attack is possible because UNIX allows any user to create a hard link to any file in the system, even those that they do not own. The attack can be implemented as follows:

1. Create a directory ($FILE_STORE_DIR) on the same file system containing the shared directory ($SHARED_DIR) without the stick bit being set.
2. Wait for spoofed user to create a file ($USER_TEMP_FILE) in shared directory.
3. Create a hard link to $USER_TEMP_FILE in the $FILE_STORE_DIR directory, with the path $USER_CAPTURED_FILE.
4. Wait for user to delete the $USER_TEMP_FILE. Now the attacker's $USER_CAPTURED_FILE is a file owned by the spoofed user with a link count of 1 in a directory without the sticky bit set.
5. Start the modified client program requiring authentication using FS or FS_REMOTE, passing the spoofed user name as the user to authenticate.
6. When the component requiring authentication requests the creation of the file, $AUTH_FILE_PATH, rename the $USER_CAPTURED_FILE to $AUTH_FILE_PATH
7. The authentication algorithm will now succeed as all the checked properties are met.

insecure permissions
incorrect semantic assumption

The cause of this is the incorrect assumption that only the owner of a file is able to create the file with a link count of 1 in a shared directory.

There are several possible mitigations to this vulnerability. The first is to create a directory instead of a file for authentication. This works as hard links to a directory are either not allowed or are only allowed by the root user. In the case of directory or file system without the directory stick bit behavior this would not be sufficient.

This could be fixed by requiring the authenticatee to create the file with permissions so that only it could write to the file, and then have it write a secret given by the authenticator into the file, and finally having the authenticator read the secret out of the file.

Another solution would be for the authenticator, running as root to create a directory that has permissions, so that only the authenticating user can create a file in the directory. Then have the authenticatee create the file in this directory.

The vulnerability was fixed in the FS authentication method by creating a directory instead of a file.

REMOTE_FS should be more secure with this fix, but due to the inherent insecurity of some remote file systems designs and implementations REMOTE_FS is vulnerable through vulnerabilities in the remote file system and should not be used.

This research funded in part by National Science Foundation under subcontract with San Diego Supercomputer Center.