Programs often rely on a predetermined file or directory to read application critical data. However, if the underlying file and directory structure is manipulated in a way that causes a program access a different, unintended file, corrupted or malicious data may be used leading to to unpredictable program behavior. This type of error is the premise for many vulnerabilities affecting UNIX symlinks and Windows shortcuts.
Once the correct file has been opened, a program is no longer vulnerable to these types of attacks so long as the file is accessed via a file descriptor. Thus, it is recommended that files are accessed through valid file handles, versus filenames.
Non-Compliant Example 1
In this example, the function chmod(...) is called twice to set the permissions of a file. However, if the file file_name is changed between calls, the permissions may be changed on a different, unintended file possibly resulting in a security vulnerability.
if (chmod("file_name", new_mode_1) == -1) {
/* Handle Error */
}
...
if (chmod("file_name", new_mode_2)== -1) {
/* Handle Error */
}
/* Process file */
Compliant Solution 1
To correct this error, the function fchmod(...) is used instead of chmod(...). The fchmod(...) operates on a file descriptor versus a file name. By using fchmod(...) it is no longer possible to change the target file between changing the file's permissions by simply changing the file that file_name refers to.
if (fchmod(fd, new_mode_1) == -1) {
/* Handle Error */
}
...
if (fchmod(fd, new_mode_2)== -1) {
/* Handle Error */
}
/* Process file */