Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.:

Code Block
bgColor#FFCCCC
langc

char *file_name;
FILE *fp;

/* initializeInitialize file_name */

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

Implementation Details

Wiki MarkupOn POSIX-compliant systems, the permissions may be restricted by the value of the POSIX {{umask()}} function \[[Open Group 2004|AA. Bibliography#Open Group 04]\].

Wiki Markup
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|AA. Bibliography#Viega 03]\]. 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:

[IEEE 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:

Code Block
Code Block

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)}}|http://www.openbsd.org/cgi-bin/man.cgi?query=open&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html] in the OpenBSD Manual Pages \ [[OpenBSD|AA. Bibliography#OpenBSD]\].)

Compliant Solution (fopen_s()

...

, C11 Annex K)

The C11 Annex K function Wiki MarkupThe ISO/IEC TR 24731-1 function {{fopen_s()}} can be used to create a file with restricted permissions \[ [ISO/IEC TR 24731-1:2007|AA. Bibliography#ISO/IEC TR 24731-1-2007]\9899:2011]:

If the file is being created, and the first character of the mode string is not 'u', to the extent that the underlying system supports it, the file shall have a file permission that prevents other users on the system from accessing the file. If the file is being created and the first character of the mode string is 'u', then by the time the file has been closed, it shall have the system default file access permissions.

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).:

Code Block
bgColor#ccccff
langc

char *file_name;
FILE *fp;

/* initializeInitialize file_name */

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

On Windows, fopen_s() will create the file with security permissions based on the user executing the application. For more controlled permission schemes, consider using the CreateFile() function and specifying the SECURITY_ATTRIBUTES parameter.

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.

Code Block
bgColor#FFCCCC
langc

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)

Access permissions for the newly created file should be specified in the third argument to open(). Again, the permissions are modified by the value of umask().

Code Block
bgColor#ccccff
langc

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 */
}

...

John Viega and Matt Messier also provide the following advice \ [[Viega 2003|AA. Bibliography#Viega 03]\]:

Do not rely on setting the umask to a "secure" value once at the beginning of the program and then calling all file or directory creation functions with overly permissive file modes. Explicitly set the mode of the file at the point of creation. There are two reasons to do this. First, it makes the code clear; your intent concerning permissions is obvious. Second, if an attacker managed to somehow reset the umask between your adjustment of the umask and any of your file creation calls, you could potentially create sensitive files with wide-open permissions.

...

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

Recommendation

Severity

Likelihood

Remediation Cost

Priority

Level

FIO06-C

medium

Medium

probable

Probable

high

High

P4

L3

Automated Detection

Tool

Version

Checker

Description

CodeSonar
Include Page
CodeSonar_V
CodeSonar_V
(customization)

CodeSonar's custom checking infrastructure allows users to implement checks such as the following.

  • A check for all uses of fopen().
  • A check for calls to open() with only two arguments.
  • A check for calls to open() where the third argument does not satisfy some specified requirement.
Helix QAC

Include Page
Helix QAC_V
Helix QAC_V

C5013
LDRA tool suite
Include Page
LDRA_V
LDRA_V
44 SEnhanced Enforcement

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 24772 "XZN Missing or Inconsistent Access Control"

...

...

...

...

...

276,

...

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

...

Insecure default permissions
CWE-279, Insecure execution-assigned permissions
CWE-732,

...

Incorrect

...

permission assignment for critical resource

Bibliography

...

[CVE]
[Dowd 2006]Chapter 9, "UNIX 1: Privileges and Files"
[IEEE Std 1003.1:2013]XSH, System Interfaces, open
XSH, System Interfaces, umask
[ISO/IEC 9899:2011]Subclause K.3.5.2.1, "The fopen_s Function"
[OpenBSD]
[Viega 2003]Section 2.7, "Restricting Access Permissions for New Files on UNIX"


...

Image Added Image Added Image Added|AA. Bibliography#CVE]\] \[[OpenBSD|AA. Bibliography#OpenBSD]\] \[[Open Group 2004|AA. Bibliography#Open Group 04]\] "The {{open}} function," and "The {{umask}} function" \[[Viega 2003|AA. Bibliography#Viega 03]\] Section 2.7, "Restricting Access Permissions for New Files on UNIX" \[[Dowd 2006|AA. Bibliography#Dowd 06]\] Chapter 9, "UNIX 1: Privileges and Files"Image Removed      09. Input Output (FIO)      FIO07-C. Prefer fseek() to rewind()