Page History

...

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

File Links

Many operating systems support file links including symbolic (soft) links, hard links, short cuts, and UNC (universal naming convention) shares. Symbolic links can be created in POSIX using the ln -s command, and hard links using the ln command. Hard links are indistinguishable from normal files on POSIX systems.

...

These limitations may lead to a program overwriting or accessing an unintended file.

Device Files

File names on many operating systems may be used to access device files. Reserved MS-DOS device names include AUX, CON, PRN, COM1, and LPT1. Character special files and block special files on POSIX systems are used to apply access rights and to direct operations on the files to the appropriate device drivers.

...

A Web browser that failed to check for these devices would allow an attacker to create a Web site with image tags such as <IMG src="file:///dev/mouse"> that would lock the user's mouse.

Shared File Access

On many systems, file can be be simultaneously accessed by concurrent processes.  Exclusive access grants unrestricted file access to the locking process while denying access to all other processes, eliminating the potential for a race condition on the locked region. The {{java.nio.channels.FileLock}} class facilitates file locking. According to the Java API \[[API 2006|AA. Bibliography#API 06]\] documentation

...

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

Noncompliant Code Example

In this noncompliant code example, an attacker could specify the name of a locked device or a FIFO file, causing the program to hang when opening a file.

String file = /* provided by user */
InputStream in = new FileInputStream(file);
// ...
in.close();

Noncompliant Code Example (Java 1.7)

This noncompliant code example uses the try-with-resources statement from Java 1.7 to open the file. While this guarantees the file's successful closure if an exception is thrown, it is subject to the same vulnerabilities as the previous example.

String filename = /* provided by user */
Path file = new File(filename).toPath();
try (InputStream in = Files.newInputStream(file)) {
   // read file
} catch (IOException x) {
  // handle error
}

Noncompliant Code Example (Java 1.7: isRegularFile())

This noncompliant code example first checks that the file is a regular file before opening it.

...

This test can still be circumvented by a symbolic link. By default, the readAttributes() method follows symbolic links and reads the file attributes of the final target of the link. The result is that the program may reference a file other than the one intended.

Noncompliant Code Example (Java 1.7: NOFOLLOW_LINKS)

This noncompliant code example checks the file by calling the readAttributes() method with the NOFOLLOW_LINKS link option to prevent the function from following symbolic links. This allows the detection of symbolic links because the isRegularFile() is made on the symbolic link file and not on the final target of the link.

...

This code is still vulnerable to a TOCTOU race condition, however. For example, an attacker can replace the regular file with a file link or device file after the code has completed its checks but before it opens the file.

Noncompliant Code Example (Java 1.7: Check-Use-Check)

This noncompliant code example performs necessary checks and then opens the file. After opening the file, it performs a second check to make sure that the file has not been moved, and that the file it opened is the same one it checked. This reduces the chance that an attacker has changed the file between checking and opening the file. In both checks, the file's fileKey attribute is examined. This serves as a unique key for identifying files, and is a more reliable indicator of a file's identity than its path name.

...

• 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 a 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 which are prescribed by IDS02-J. Canonicalize path names before validating them.

Compliant Solution (POSIX, Java 1.7, secure directory)

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 path name is not in a secure directory.

...

Programs with elevated privileges may need to write files to directories owned by unprivileged users. One example would be a mail daemon that reads a mail message from one user, and places it in a directory owned by another user. In such cases, the proper course of action is to assume the privileges of a user when reading or writing files on behalf of that user, in which case all file access should occur in secure directories relative to that user. If a program with elevated privileges must write files on it's own behalf, then these files should be in secure directories relative to the privileges of the program (such as directories accessible only by the superuser).

Exceptions

FIO04-EX0: Programs that operate on single user systems, or on systems where there are no shared directories or no possibility of file system vulnerabilities, do not need to ensure that files are maintained in secure directories before operating on them.

Risk Assessment

Allowing operations to be performed on files in shared directories can result in denial-of-service attacks. If the program has elevated privileges, then privilege escalation exploits become possible.

Related Vulnerabilities

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

Related Guidelines

Bibliography

...