Files can often be identified by attributes other attributes in addition to than the file name, for example, such as by comparing file ownership or creation time. Information about a file that has been created and closed can be stored and then used to validate the identity of the file when it is reopened.
...
File identification is less of an issue if applications maintain their files in secure directories, where they can only be accessed only by the owner of the file and (possibly) by a system administrator. (See recommedation FIO15-C. Ensure that file operations are performed in a secure directory.)
Noncompliant Code Example (Reopen)
The following This noncompliant code example opens a file for writing, closes it, opens the same named file for reading, and then closes it again. The logic relies solely on the file name to identify the file.
| Code Block | ||||
|---|---|---|---|---|
| ||||
char *file_name; /* initializeInitialize file_name */ FILE *fd = fopen(file_name, "w"); if (fd == NULL) { /* Handle error */ } /*... writeWrite to file ...*/ fclose(fd); fd = NULL; /* * A race condition here allows for an attacker to switch * to switch out the file for another. */ /* ... */ fd = fopen(file_name, "r"); if (fd == NULL) { /* Handle error */ } /*... readRead from file ...*/ fclose(fd); fd = NULL; |
There is no guarantee that the file opened for reading is the same file that is opened for writing. An attacker can replace the original file (for example, with a symbolic link) between the first fclose() and the second fopen().
Compliant Solution (POSIX) (
...
Device/
...
I-node)
Reopening a file stream should generally be avoided. However, this it may sometimes be necessary in long-running applications to avoid depleting available file descriptors.
This compliant solution uses a "check, use, check" pattern to ensure that the file opened for reading is the same file that was opened for writing. In this solution, the file is opened for writing using the open() function. If the file is successfully opened, the fstat() function is used to read information about the file into the orig_st structure. When the file is reopened for reading, information about the file is read into the new_st structure, and the st_dev and st_ino fields in orig_st and new_st are compared to improve identification.
| Code Block | ||||
|---|---|---|---|---|
| ||||
struct stat orig_st; struct stat new_st; char *file_name; /* initializeInitialize file_name */ int fd = open(file_name, O_WRONLY); if (fd == -1) { /* Handle error */ } /*... writeWrite to file ...*/ if (fstat(fd, &orig_st) == -1) { /* Handle error */ } close(fd); fd = -1; /* ... */ fd = open(file_name, O_RDONLY); if (fd == -1) { /* Handle error */ } if (fstat(fd, &new_st) == -1) { /* Handle error */ } if ((orig_st.st_dev != new_st.st_dev) || (orig_st.st_ino != new_st.st_ino)) { /* fileFile was tampered with! */ } /*... readRead from file ...*/ close(fd); fd = -1; |
This solution enables the program to recognize if an attacker has switched files between the first close() and the second open(). The program does not recognize if recognize whether the file has been modified in - place, however.
Alternatively, the same solution can be implemented using the C99 C fopen() function to open the file and the POSIX fileno() function to convert the FILE object pointer to a file descriptor.
The structure members st_mode, st_ino, st_dev, st_uid, st_gid, st_atime, st_ctime, and st_mtime all should all have meaningful values for all file types on POSIX-compliant systems. The st_ino field contains the file serial number. The st_dev field identifies the device containing the file. The st_ino and st_dev fields, taken together, uniquely identify the file. The st_dev value is not necessarily consistent across reboots or system crashes; , however, so you this field may not be able to use this field useful for file identification if there is a possibility of a system crash or reboot may have occurred before you attempt to reopen a file.
Call the fstat() function on a file that is already opened instead of calling stat() on a file name followed by open(). This Doing so ensures that the file for which the information is being collected is the same file that is already opened. See recommendation FIO01-C. Be careful using functions that use file names for identification for more information on avoiding race conditions resulting from the use of file names for identification.
It may also be necessary to call open() with O_NONBLOCK, as per rule FIO32-C. Do not perform operations on devices that are only appropriate for files, to ensure that the program does not hang when trying to open special files.
This compliant solution may not work in some cases. For instance, a long-running service might choose to occasionally reopen a log file to add log messages , but leave the file closed , so that the log file may be periodically rotated. In this case, the inode i-node number would change, and this solution would no longer apply.
Compliant Solution (POSIX) (
...
Open Only Once)
A simpler solution is to not reopen the file. In this code example, the file is opened once for both writing and reading. Once writing is complete, the fseek() function resets the file pointer to the beginning of the file, and its contents are read back. (See recommendation void FIO07-C. Prefer fseek() to rewind().)
Because the file is not reopened, the possibility of an attacker tampering with the file between the writes and subsequent reads is eliminated.
| Code Block | ||||
|---|---|---|---|---|
| ||||
char *file_name; FILE *fd; /* initializeInitialize file_name */ fd = fopen(file_name, "w+"); if (fd == NULL) { /* Handle error */ } /*... writeWrite to file ...*/ /* goGo to beginning of file */ fseek(fd, 0, SEEK_SET); /*... readRead from file ...*/ fclose(fd); fd = NULL; |
Be sure to use fflush() after writing data to the file, in accordance with rule FIO39-C. Do not alternately input and output from a stream without an intervening flush or positioning call.
...
In this noncompliant code example, the programmer's intent is to open a file for reading, but only if the user running the process owns the specified file. This requirement is a more restrictive requirement than that imposed by the operating system, which requires only requires that the effective user have permissions to read the file. The code, however, relies solely on the file name to identify the file.
| Code Block | ||||
|---|---|---|---|---|
| ||||
char *file_name; FILE *fd; /* initializeInitialize file_name */ fd = fopen(file_name, "r+"); if (fd == NULL) { /* Handle error */ } /* readRead user's file */ fclose(fd); fd = NULL; |
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
struct stat st; char *file_name; /* initializeInitialize file_name */ int fd = open(file_name, O_RDONLY); if (fd == -1) { /* Handle error */ } if ((fstat(fd, &st) == -1) || (st.st_uid != getuid()) || (st.st_gid != getgid())) { /* fileFile does not belong to user */ } /*... readRead from file ...*/ close(fd); fd = -1; |
...
Alternatively, the same solution can be implemented using the C99 C fopen() function to open the file and the POSIX fileno() function to convert the FILE object pointer to a file descriptor.
Risk Assessment
Many file-related vulnerabilities are exploited to cause a program to access an unintended file. Proper file identification is necessary to prevent exploitation.
Recommendation | Severity | Likelihood |
|---|
Detectable | Repairable | Priority | Level |
|---|---|---|---|
FIO05-C |
Medium | Probable |
No |
No |
P4 |
L3 |
Automated Detection
Tool | Version | Checker | Description |
|---|
| Compass/ROSE |
Could report possible violations of this rule merely by reporting any | |||||||||
| LDRA tool suite |
| 44 S | Enhanced Enforcement |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
...
...
...
ISO/IEC TR 24772 "EWR Path Traversal"
...
| TR 24772:2013 | Path Traversal [EWR] |
| MITRE CWE |
...
| Path issue—Slash absolute path CWE-38, |
...
| Path Issue—Backslash absolute path CWE-39, |
...
| Path Issue—Drive letter or Windows |
...
| volume |
...
...
| -62, |
...
| UNIX |
...
| hard link |
...
...
| -64, |
...
| Windows |
...
| shortcut following (.LNK) |
...
...
...
| Windows |
...
| hard link |
Bibliography
...
| [ |
...
...
...
| ] | Section 2.2.1 |
...
| "Identification |
...
| when Opening" | |
| [IEEE Std 1003.1:2013] | System Interfaces: openSystem Interfaces: fstat |
| [Seacord 2013] | Chapter 8, "File I/O" |
...
\[[Open Group 2004|AA. Bibliography#Open Group 04]\] "The open function," and "The fstat function" \[[Seacord 2005|AA. Bibliography#Seacord 05]\] Chapter 7, "File I/O"FIO04-C. Detect and handle input and output errors 09. Input Output (FIO)