Page History

Many file-related security vulnerabilities result from a program accessing a file object different from the one intended. In the C programming language, character-based filenames are an unintended file object because file names are only loosely bound to underlying file objects in name only. Filenames File names provide no information regarding the nature of the file object itself. Furthermore, the binding of a filename file name to a file object is reasserted every time the filename file name is used in an operation. File descriptors and FILE pointers are bound to underlying file objects by the operating system. Operating on . (See FIO03-C. Do not make assumptions about fopen() and file creation.)

Accessing files via file descriptors instead of filenames or FILE pointers rather than file names provides a greater level degree of certainty with regard as to the which object that is actually acted onupon. Thus, it It is recommended that files are be accessed through file descriptors or FILE pointers where possible.

The following C functions rely solely on file names for file identification:

• remove()
• rename()
• fopen()
• freopen()

Use these functions with caution. See FIO10-C. Take care when using the rename() function, and FIO08-C. Take care when calling remove() on an open file.

Noncompliant Code Example

In this noncompliant code example, the file identified by file_name is opened, processed, closed, not filenames.

Non-Compliant Example 1

and removed. However, it is possible that the file object identified by file_name in the call to remove() is not the same file object identified by file_name in the call to fopen().

char *file_name;
FILE *f_ptr;

/* Initialize file_name */

f_ptr = fopen(file_name, "w");
if (f_ptr == NULL) {
  /* Handle error */
}

/*... Process file ...*/

if (fclose(f_ptr) != 0) {
  /* Handle error */
}

if (remove(file_name) != 0) {
  /* Handle error */
}

Compliant Solution

Not much can be done programmatically to ensure the file removed is the same file that was opened, processed, and closed except to make sure that the file is opened in a secure directory with privileges that would prevent the file from being manipulated by an untrusted user. (See FIO15-C. Ensure that file operations are performed in a secure directory.)

Noncompliant Code Example (POSIX)

In this noncompliant code In this example, the function chmod() is called to set the permissions of a file. However, it is not clear whether the file object referred to by file_name refers to the same object in the call to fopen() and in the call to chmod().

char *file_name;

...
FILE * f_ptr;

/* =Initialize fopen(file_name,"w"); */

f_ptr = fopen(file_name, "w");
if (!f_ptr == NULL)  {
  /* Handle fopen()error Error */
}

/* ... */

if (chmod(file_name, newS_modeIRUSR) == -1) {
  /* Handle chmod()error Error */
}
/* Process file */

Compliant Solution

...

(POSIX)

This compliant solution uses the POSIX fchmod() and open() functions [IEEE Std 1003.1:2013]. Using these functions guarantees Using functions similar to those above but that operate on file descriptors rather than filenames provides a greater level of certainty that the file opened is the same file that is operated on.

char *file_name;
int fd;

/* Initialize file_name */

...
fd = open(
  file_name,
  O_WRONLY | O_CREAT | O_EXCL,
 0600 S_IRWXU
);

if (fd == -1) {
  /* Handle open() error */
}

/* ... */

if (fchmod(fd, newS_modeIRUSR) == -1) {
  /* Handle fchmod() Errorerror */
}
/* Process file */
...

References

...

Mitigation Strategies (POSIX)

Many file-related race conditions can be eliminated by using

• fchown() rather than chown()
• fstat() rather than stat()
• fchmod() rather than chmod()

or simply by ensuring the security of the working directory per FIO15-C. Ensure that file operations are performed in a secure directory.

POSIX functions that have no file descriptor counterpart should be used with caution:

• link() and unlink()
• mkdir() and rmdir()
• mount() and unmount()
• lstat()
• mknod()
• symlink()
• utime()

Risk Assessment

Many file-related vulnerabilities, such as time-of-check, time-of-use (TOCTOU) race conditions, can be exploited to cause a program to access an unintended file. Using FILE pointers or file descriptors to identify files instead of file names reduces the chance of accessing an unintended file. Remediation costs are medium because, although insecure functions can be easily identified, simple drop-in replacements are not always available.

Automated Detection

Related Vulnerabilities

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

Related Guidelines

Bibliography

...

Image Added Image Added Image Added

...