Failing to close files when they are no longer needed may allow attackers to exhaust, and possibly manipulate, system resources. This phenomenon is typically referred to as file descriptor leakage, although file pointers may also be used as an attack vector. To prevent file descriptor leaks, files should be closed when they are no longer needed.
Be careful not to close the standard streams (especially stdout
): doing so will send an EOF
to any application on the other side of a pipe, possibly causing it to take actions that shouldn't have occurred until the first application terminates.
Noncompliant Code Example
In this noncompliant code example derived from a vulnerability in OpenBSD's chpass
program [[NAI 98]], a file containing sensitive data is opened for reading. The program then retrieves the registered editor from the EDITOR
environment variable and executes it using the system()
command. If, the system()
command is implemented in a way that spawns a child process, then the child process inherits the file descriptors opened by its parent. As a result, the child process, which in this example is the program specified by the EDITOR
environment variable, will be able to access the contents of the potentially sensitive file called file_name
.
FILE* f; const char *editor; char *file_name; /* Initialize file_name */ f = fopen(file_name, "r"); if (f == NULL) { /* Handle fopen() error */ } /* ... */ editor = getenv("EDITOR"); if (editor == NULL) { /* Handle getenv() error */ } if (system(editor) == -1) { /* Handle error */ }
On UNIX-based systems, child processes are typically spawned using a form of fork()
and exec()
, and the child process always receives copies of its parent's file descriptors. Under Microsoft Windows, the CreateProcess()
function is typically used to start a child process. In Windows, file-handle inheritance is determined on a per-file bases. Additionally, the CreateProcess()
function itself provides a mechanism to limit file-handle inheritance. As a result, the child process spawned by CreateProcess()
may not receive copies of the parent process's open file handles.
Compliant Solution
In this compliant solution, file_name
is closed before launching the editor.
FILE* f; const char *editor; char *file_name; /* Initialize file_name */ f = fopen(file_name, "r"); if (f == NULL) { /* Handle fopen() error */ } /* ... */ fclose(f); f = NULL; editor = getenv("EDITOR"); if (editor == NULL) { /* Handle getenv() error */ } /* Sanitize environment before calling system()! */ if (system(editor) == -1) { /* Handle Error */ }
Several security issues remain in this example. Compliance with recommendations, such as STR02-CPP. Sanitize data passed to complex subsystems and FIO02-CPP. Canonicalize path names originating from untrusted sources is necessary to prevent exploitation. However, these recommendations do not address the specific issue of file descriptor leakage addressed here.
Compliant Solution (POSIX)
Sometimes it is not practical for a program to close all active file descriptors before issuing a system call such as system()
or exec()
. An alternative on POSIX systems is to use the FD_CLOEXEC
flag, or O_CLOEXEC
when available, to set the close-on-exec flag for the file descriptor.
int flags; char *editor; char *file_name; /* Initialize file_name */ int fd = open(file_name, O_RDONLY); if (fd == -1) { /* Handle error */ } flags = fcntl(fd, F_GETFD); if (flags == -1) { /* Handle error */ } if (fcntl(fd, F_SETFD, flags | FD_CLOEXEC) == -1) { /* Handle error */ } /* ... */ editor = getenv("EDITOR"); if (editor == NULL) { /* Handle getenv() error */ } if (system(editor) == -1) { /* Handle error */ }
Some systems (such as those with Linux kernel versions greater than or equal to 2.6.23) have an O_CLOEXEC
flag that provides the close-on-exec function directly in open()
. This flag is required by POSIX.1-2008 [[Austin Group 08]]. In multithreaded programs, this flag should be used if possible because it prevents a timing hole between open()
and fcntl()
when using FD_CLOEXEC
, during which another thread can create a child process while the file descriptor does not have close-on-exec set.
char *editor; char *file_name; /* Initialize file_name */ int fd = open(file_name, O_RDONLY | O_CLOEXEC); if (fd == -1) { /* Handle error */ } /* ... */ editor = getenv("EDITOR"); if (editor == NULL) { /* Handle getenv() error */ } if (system(editor) == -1) { /* Handle error */ }
Risk Assessment
Failing to properly close files may allow unintended access to, or exhaustion of, system resources.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
FIO42-CPP |
medium |
unlikely |
medium |
P4 |
L3 |
Automated Detection
The LDRA tool suite Version 7.6.0 can detect violations of this recommendation.
Fortify SCA Version 5.0 with CERT C Rule Pack can detect violations of this recommendation.
Klocwork Version 8.0.4.16 can detect violations of this rule with the RH.LEAK checker.
Compass/ROSE can detect violations of this rule.
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Other Languages
This rule appears in the C Secure Coding Standard as FIO42-C. Ensure files are properly closed when they are no longer needed.
This rule appears in the Java Secure Coding Standard as FIO06-J. Ensure all resources are properly closed when they are no longer needed.
References
[[Austin Group 08]]
[[Dowd 06]] Chapter 10, "UNIX Processes" (File Descriptor Leaks 582-587)
[[MITRE 07]] CWE-404, "Improper Resource Shutdown or Release," and CWE-403, "UNIX File Descriptor Leak," CWE-770, "Allocation of Resources Without Limits or Throttling"
[[MSDN]] Inheritance (Windows)
[[NAI 98]]
FIO41-CPP. Do not call getc() or putc() with stream arguments that have side effects 09. Input Output (FIO) FIO43-CPP. Do not create temporary files in shared directories