Page History

Multiuser systems allow multiple users with different privileges to share a filesystem. Each user, in such an environment, must be able to determine which files are shared and which are private and each user must be able to enforce these decisions.

Unfortunately, there are a wide variety of file system vulnerabilities that can be exploited by an attacker to gain access to files for which they lack sufficient privileges, particularly when operating on files that reside in shared directories in which multiple users may create, move, or delete files. Privilege escalation is also possible in cases where these programs run with elevated privileges. To prevent these exploits, a program must only operate on files in secure directories.

A directory is secure with respect to a particular user if the user has exclusive privileges to move or delete files inside the directory. Furthermore, each parent to the secure directory can only be be moved or deleted by the user and the system administrator. On most systems, home or user directories are secure by default and only shared directories are insecure.

There are a number of files system filesystem properties and capabilities that can be exploited by an attacker including file links, device files, and shared file access.

...

Linux implements both mandatory locks and advisory locks. Advisory locks are not enforced by the operating system, which diminishes their value from a security perspective. Unfortunately, the mandatory file lock in Linux is generally impractical because:

• Mandatory locking is only supported by certain network file systems.
• File systems must be mounted with support for mandatory locking, and this is disabled by default.
• Locking relies on the group ID bit, which can be turned off by another process (thereby defeating the lock).
• The lock is implicitly dropped if the holding process closes any descriptor of the file.

...

• A TOCTOU race condition exists between the first check and open. During this race window, an attacker can replace the regular file with a symbolic link or other non-regular file. The second check detects this race condition but does not eliminate it; an attacker can still cause the system to block when opening the file.
• An attacker could subvert this code by letting the check operate on a normal file, substituting the non-normal file for the open, and then resubstitute the normal file to circumvent the second check. This vulnerability exists because Java lacks any mechanism to obtain file attributes from a file by any means other than the file name, and the binding of the file name to a file object is reasserted every time the file name is used in an operation. Consequently, an attacker can still switch out a file for one of the file types shown in the following table with the specified effecta nefarious file, such as a symbolic link.
• A system with hard links allows an attacker to construct a malicious file that is a hard link to a sensitive file. Hard links cannot be reliably detected by a program, and serve as a foil to canonicalization attempts , as recommended which are prescribed by IDS21-J. Canonicalize path names before validating them.

...

Because of the potential for race conditions, and the inherent accessibility of shared directories, files must only be operated upon in secure directories. Because programs may run with reduced privileges and lack the facilities to construct a secure directory, a program may need to throw an exception if it can determine that a given a path name is not in a secure directory.

Following is an implementation of an isInSecureDir() method. This method ensures that the supplied file and all directories above it are owned by either the user or the superuser, that each directory lacks write access for any other users, and that directories above the given file may not be deleted or renamed by any other users (except the superuser).

/**
 * Indicates if file lives in a secure directory relative to the program's user
 * @param file Path to test
 * @return true if file's directory is secure
 */
public static boolean isInSecureDir(Path file) {
  return isInSecureDir( file, null);
}

/**
 * Indicates if file lives in a secure directory relative to the program's user
 * @param file Path to test
 * @param user User to test. If null defaults to current user
 * @return true if file's directory is secure
 */
public static boolean isInSecureDir(Path file, UserPrincipal user) {
  if (!file.isAbsolute()) {
    file = file.toAbsolutePath();
  }

  // If any parent dirs (from root on down) are not secure, dir is not secure
  for (int i = 1; i <= file.getNameCount(); i++) {
    Path partialPath = Paths.get(file.getRoot().toString(), file.subpath(0, i).toString());

    try {
      if (Files.isSymbolicLink(partialPath)) {
        if (!isInSecureDir(Files.readSymbolicLink(partialPath))) {
          // Symbolic link, linked-to dir not secure
          return false;
        }
      } else {
        FileSystem fileSystem = partialPath.getFileSystem();
        UserPrincipalLookupService upls = fileSystem.getUserPrincipalLookupService();
        UserPrincipal root = upls.lookupPrincipalByName("root");
        if (user == null) {
          user = upls.lookupPrincipalByName(System.getProperty("user.name"));
        }
        UserPrincipal owner = Files.getOwner(partialPath);
        if (!owner.equals(user) && !owner.equals(root)) {
          // dir owned by someone else, not secure
          return false;
        }
        PosixFileAttributes attr = Files.readAttributes(partialPath, PosixFileAttributes.class);
        Set<PosixFilePermission> perms = attr.permissions();
        if (perms.contains(PosixFilePermission.GROUP_WRITE) ||
            perms.contains(PosixFilePermission.OTHERS_WRITE)) {
          // someone else can write files, not secure
          return false;
        }
      }
    } catch (IOException x) {
      return false;
    }
  }

  return true;
}

...

Related Vulnerabilities

GERONIMO-3489

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

...

...