MSC09-A. Character Encoding - Use Subset of ASCII for Safety

According to C99, Section 5.2.1, "Character sets"

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 referred as US-ASCII. The international standard ISO 646 [[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. It also gives some liberties with characters #$^`~. In ISO 646, several national variants of ASCII"\ have been 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. Consequently, due to the national variants, some characters are less portable than others--they might be transferred or interpreted incorrectly.

In addition to the letters of the English alphabet ("A" through "Z" and "a" through "z"), the digits ("0" through "9"), and the space, only the following characters are portable:

% & + , - . : = _

When naming files, variables, etc., only these characters should be considered for use. This recommendation is related to STR02-A. 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 filename in the creation or renaming of a file, certain checks should be made to disallow the following characters and patterns:

• Leading dashes
• Control characters such as newlines, carriage returns, and escape
• Spaces
• Invalid character encodings
• Any characters other than letters, numbers, and punctuation designated above as portable

Many of the punctuation characters aren't unconditionally safe for filenames even of they are portably available.

Most of these characters or patterns are primarily a problem to scripts or automated parsing, but because they are not commonly used, it is best to disallow their use to reduce potential problems.  Interoperability concerns also exist because different operating systems handle filenames of this sort in different ways.  Leading dashes can cause programs when programs are called with this filename as a parameter, the first character or characters of the file might be taken to mean that its an option switch.  Control characters in a filename can cause unexpected results from shell scripts and in logging.  Spaces can again cause problems with scripts and anytime double quotes aren't used to surround the filename.  Character encodings can be a huge issue and are also discussed in MSC10-A. Character Encoding - UTF8 Related Issues.  Other special characters are included in this recommendation because they are commonly used as separators and having them in a filename can cause unexpected and potentially insecure behavior.

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. In some cases file names are case sensitive while in other cases 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 ]].

Non-Compliant Coding Example: Encoding

In the following non-compliant code, unsafe characters are used as part of a filename.

#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 non-"safe" characters. For example, when tested on a Red Hat Linux distribution, this non-compliant code example resulted in the following file name:

??????

Compliant Solution: Encoding

Use a descriptive filename, containing only the subset of ASCII described above.

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

int main(void) {
   char *file_name = "name.ext";
   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 */
   }
}

Non-Compliant Code Example (File Name)

This non-compliant 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.

char myFilename[1000];
char const elimNewLn[] = "\n";

fgets(myFilename, sizeof(myFilename)-1, stdin);
myFilename[sizeof(myFilename)-1] = '\0';
myFilename[strcspn(myFilename, elimNewLn)] = '\0';

No checks are performed on the filename to prevent troublesome characters.  If an attacker knew this code was in a program used to create or rename files that would later be used in a script or automated process of some sort, they could choose particular characters in the output filename to confuse the later process for malicious purposes.

Compliant Solution (File Name)

In this compliant solution, the program rejects filenames that violate the guidelines for selecting safe characters.

char myFilename[1000];
char const elimNewln[] = "\n";
char const badChars[] = "-\n\r ,;'\\<\"";
do {
  fgets(myFilename, sizeof(myFilename)-1, stdin);
  myFilename[sizeof(myFilename)-1] ='\0';
  myFilename[strcspn(myFilename, elimNewln)]='\0';
} while ( (strcspn(myFilename, badChars)) < (strlen(myFilename)));

Similarly, you must provide validate all filenames originating from untrusted sources to ensure they contain only safe characters.

Risk Assessment

Failing to use only the subset of ASCII guaranteed to work can result in misinterpreted data.

Automated Detection

The LDRA tool suite V 7.6.0 is able to detect violations of this recommendation.

References

[[Kuhn 06]] UTF-8 and Unicode FAQ for Unix/Linux
[[ISO/IEC 646-1991]] ISO 7-bit coded character set for information interchange
[[ISO/IEC 9899-1999]] Section 5.2.1, "Character sets"
[[MISRA 04]] 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"
[[Wheeler 03]] 5.4 File Names
[[VU#881872]]

MSC08-A. Library functions should validate their parameters      13. Miscellaneous (MSC)       MSC10-A. Character Encoding - UTF8 Related Issues