Page History

...

When setting access permissions, it is important to make sure that an attacker is not able to cannot alter them. (See recommendation FIO15-C. Ensure that file operations are performed in a secure directory.)

...

The fopen() function does not allow the programmer to explicitly specify file access permissions. In this noncompliant code example, if the call to fopen() creates a new file, the access permissions are implementation-defined.:

char *file_name;
FILE *fp;

/* initializeInitialize file_name */

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

...

On POSIX-compliant systems, the permissions may be restricted by the value of the POSIX umask() function [Open Group 2004IEEE Std 1003.1:2013].

The operating system modifies the access permissions by computing the intersection of the inverse of the umask and the permissions requested by the process [Viega 2003]. For example, if the variable requested_permissions contained the permissions passed to the operating system to create a new file, the variable actual_permissions would be the actual permissions that the operating system would use to create the file:

requested_permissions = 0666;
actual_permissions = requested_permissions & ~umask();

For OpenBSD and Linux operating systems, any file created will have mode S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH (0666), as modified by the process's umask value. (See fopen(3) in the OpenBSD Manual Pages [OpenBSD].)

Compliant Solution (fopen_s() ISO/IEC TR 24731-1)

The ISO/IEC TR 24731-1 function fopen_s() can be used to create a file with restricted permissions [ISO/IEC TR 24731-1:2007]:

...

The u character can be thought of as standing for "umask," meaning that these are the same permissions that the file would have been created with had it been created by fopen(). In this compliant solution, the u mode character is omitted so that the file is opened with restricted privileges (regardless of the umask).

char *file_name;
FILE *fp;

/* initialize file_name */

errno_t res = fopen_s(&fp, file_name, "w");
if (res != 0) {
  /* Handle error */
}

Noncompliant Code Example (open(), POSIX)

Using the POSIX open() function to create a file , but failing to provide access permissions for that file , may cause the file to be created with overly permissive access permissions. This omission has been known to lead to vulnerabilities, for —for example, CVE-2006-1174.

char *file_name;
int fd;

/* initializeInitialize file_name */

fd = open(file_name, O_CREAT | O_WRONLY);
/* accessAccess permissions were missing */

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

This example also violates rule EXP37-C. Call functions with the arguments intended by the APIcorrect number and type of arguments.

Compliant Solution (open(), POSIX)

...

char *file_name;
int file_access_permissions;

/* initializeInitialize file_name and file_access_permissions */

int fd = open(
  file_name,
  O_CREAT | O_WRONLY,
  file_access_permissions
);
if (fd == -1){
  /* Handle error */
}

...

Creating files with weak access permissions may allow unintended access to those files.

Automated Detection

Related Vulnerabilities

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

Related Guidelines

...

...

...

ISO/IEC 9899:1999 Section 7.19.5.3, "The fopen function"

...

ISO/IEC TR 24731-1:2007 Section 6.5.2.1, "The fopen_s function"

...

...

...

...

...

MITRE CWE: CWE-276, "Insecure Default Permissions"

...

...

...

Bibliography

...

...

...

Image Modified Image Modified Image Modified