Page History

...

Two sets of characters and their associated collating sequences shall be defined: the set in which source files are written (the source character set), and the set interpreted in the execution environment (the execution character set). Each set is further divided into a basic character set, whose contents are given by this subclause, and a set of zero or more locale-specific members (which are not members of the basic character set) called extended characters. The combined set is also called the extended character set. The values of the members of the execution character set are implementation-defined.

There are several national variants of ASCII. As a result, the original ASCII is often called US-ASCII. ISO/IEC 646-1991 defines a character set, similar to US-ASCII, but with code positions corresponding to US-ASCII characters @[]{|} as national use positions [ISO/IEC 646-1991]. It also gives some liberties with the characters #$^`~. In ISO/IEC 646-1991, several national variants of ASCII are defined, assigning different letters and symbols to the national use positions. Consequently, the characters that appear in those positions, including those in US-ASCII, are less portable in international data transfer. Because of the national variants, some characters are less portable than others: they might be transferred or interpreted incorrectly.

...

When naming files, variables, and other objects, only these characters should be considered for use. This recommendation is related to STR02-C. Sanitize data passed to complex subsystems.

File Names

File names containing particular characters can be troublesome and can cause unexpected behavior leading to potential vulnerabilities. If a program allows the user to specify a file name in the creation or renaming of a file, certain checks should be made to disallow the following characters and patterns:

...

As a result of the influence of MS-DOS, file names of the form xxxxxxxx.xxx, where x denotes an alphanumeric character, are generally supported by modern systems. On some platforms, file names are case sensitive, and on other platforms, they are case insensitive. VU#439395 is an example of a vulnerability resulting from a failure to deal appropriately with case-sensitivity issues [VU#439395].

Noncompliant Code Example (File Name 1)

...

#include <fcntl.h>
#include <sys/stat.h>

int main(void) {
   char *file_name = "&#xBB;&#xA3;???&#xAB;";
   mode_t mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH;

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

An implementation is free to define its own mapping of the "nonsafe" characters. For example, when tested on a Red Hat Linux distribution, this noncompliant code example resulted in the following file name:

...

This noncompliant code example is derived from FIO30-C. Exclude user input from format strings, except that a newline is removed on the assumption that fgets() will include it.

...

Related Vulnerabilities

...

The CERT Oracle Secure Coding Standard for Java: IDS05-J. Use a subset of ASCII for file and path names

ISO/IEC 646-1991 ISO 7-bit coded character set for information interchange

ISO/IEC 9899:2011 Section 5.2.1, "Character sets"

ISO/IEC TR 24772 "AJN Choice of filenames and other external edentifiers"

MISRA Rule 3.2, "The character set and the corresponding encoding shall be documented," and Rule 4.1, "Only those escape sequences that are defined in the ISO C Standard shall be used"

MITRE CWE: CWE-116, "Improper encoding or escaping of output"

Sources

[Kuhn 2006] UTF-8 and Unicode FAQ for UNIX/Linux
[Wheeler 2003] 5.4, "File names"
[VU#439395]

...