According to subclause 5.2.1 of the C Standard [ISO/IEC 9899:2011],
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 particular characters (e.g., #$^`~). 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:
The character encoding defined by the ASCII standard is the following: code values are assigned to characters consecutively in the order in which the characters are listed as the table below: starting from 32 (assigned to space) and ending up with 126 (assigned to the tilde character ~). Positions 0 through 31 and 127 are reserved for control codes.
...
...
!
...
"
...
#
...
$
...
%
...
&
...
'
...
(
...
)
...
*
...
+
...
,
...
-
...
.
...
/
...
0
...
1
...
2
...
3
...
4
...
5
...
6
...
7
...
8
...
9
...
:
...
;
...
<
...
=
...
>
...
?
...
@
...
A
...
B
...
C
...
D
...
E
...
F
...
G
...
H
...
I
...
J
...
K
...
L
...
M
...
N
...
O
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="66e175f5-840e-40a0-868e-4851e4d3e4ed"><ac:plain-text-body><![CDATA[
...
P
...
Q
...
R
...
S
...
T
...
U
...
V
...
W
...
X
...
Y
...
Z
...
[
...
\
...
]
...
^
...
_
...
]]></ac:plain-text-body></ac:structured-macro>
...
'
...
a
...
b
...
c
...
d
...
e
...
f
...
g
...
h
...
i
...
j
...
k
...
l
...
m
...
n
...
o
...
p
...
q
...
r
...
s
...
t
...
u
...
v
...
w
...
x
...
y
...
z
...
{
...
|
...
}
...
~
| Wiki Markup |
|---|
There are several national variants of ASCII. Therefore, the original ASCII is often referred as *US-ASCII*. The international standard _ISO 646_ 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. Thus, the characters that appear in those positions - including those in *US-ASCII* are somewhat "unsafe" in international data transfer. |
Thus, due to the "national variants" discussed above, some characters are less "safe" than others, for example, they might be transferred or interpreted incorrectly.
In Addition addition to the letters of the English alphabet ("A " to "through Z " and " a " to "through z"), the digits ("0 " to "through 9"), and the space, only the following characters can be regarded as really "safe" in data transmissionare portable:
| No Format |
|---|
! " % & ' ( ) * + , - . / : ; < = > ?_ |
When naming files, variables, data files etc., it is often best to use only the characters listed above.
Comments
The way to resolve this issue is to use the corresponding codes strictly for US-ASCII meanings; national characters are handled otherwise, giving them their own, unique and universal code positions in character codes larger than ASCII. But certain old softwares and devices may still reflect various "national variants of ASCII".
Risk Assessment
This issue will result data lost or data mis-interpretation during data transmission. This can be a serious security issue. There are already solutions which address this issue pretty well. (See "Comments" section)
Reference
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:
- Leading dashes—Leading dashes can cause problems when programs are called with the file name as a parameter because the first character or characters of the file name might be interpreted as an option switch.
- Control characters, such as newlines, carriage returns, and escape—Control characters in a file name can cause unexpected results from shell scripts and in logging.
- Spaces—Spaces can cause problems with scripts and when double quotes are not used to surround the file name.
- Invalid character encodings—Character encodings can be a huge issue. (See MSC10-C. Character encoding: UTF8-related issues.)
- Any characters other than letters, numbers, and punctuation designated here as portable—Other special characters are included in this recommendation because they are commonly used as separators, and having them in a file name can cause unexpected and potentially insecure behavior.
Also, many of the punctuation characters are not unconditionally safe for file names 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 file names of this sort in different ways.
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)
In this noncompliant code example, unsafe characters are used as part of a file name:
| Code Block | ||||
|---|---|---|---|---|
| ||||
#include <fcntl.h>
#include <sys/stat.h>
int main(void) {
char *file_name = "\xe5ngstr\xf6m";
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 run on Red Hat Enterprise Linux 7.5, this noncompliant code example resulted in the following file name being revealed by the ls command:
| Code Block |
|---|
?ngstr?m
|
Compliant Solution (File Name 1)
Use a descriptive file name containing only the subset of ASCII previously described:
| Code Block | ||||
|---|---|---|---|---|
| ||||
#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 */
}
}
|
Noncompliant Code Example (File Name 2)
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:
| Code Block | ||||
|---|---|---|---|---|
| ||||
char myFilename[1000];
const char elimNewLn[] = "\n";
fgets(myFilename, sizeof(myFilename)-1, stdin);
myFilename[sizeof(myFilename)-1] = '\0';
myFilename[strcspn(myFilename, elimNewLn)] = '\0';
|
No checks are performed on the file name 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, he or she could choose particular characters in the output file name to confuse the later process for malicious purposes.
Compliant Solution (File Name 2)
In this compliant solution, the program rejects file names that violate the guidelines for selecting safe characters:
| Code Block | ||||
|---|---|---|---|---|
| ||||
char myFilename[1000];
const char elimNewln[] = "\n";
const char 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 validate all file names originating from untrusted sources to ensure they contain only safe characters.
Risk Assessment
Failing to use only the subset of ASCII that is guaranteed to work can result in misinterpreted data.
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
MSC09-C | Medium | Unlikely | Medium | P4 | L3 |
Automated Detection
Tool | Version | Checker | Description | ||||||
|---|---|---|---|---|---|---|---|---|---|
| Astrée |
| bitfield-name | Partially checked | ||||||
| Helix QAC |
| C0285, C0286, C0287, C0288, C0289, C0299 | |||||||
| LDRA tool suite |
| 113 S | Partially implemented | ||||||
| Parasoft C/C++test |
| CERT_C-MSC09-a | Only use characters defined in the ISO C standard | ||||||
| RuleChecker |
| bitfield-name | Partially checked | ||||||
| SonarQube C/C++ Plugin |
| S1578 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
| SEI CERT C++ Coding Standard | VOID MSC09-CPP. Character encoding: Use subset of ASCII for safety |
| CERT Oracle Secure Coding Standard for Java | IDS50-J. Use conservative file naming conventions |
| MISRA C:2012 | Directive 1.1 (required) Rule 4.1 (required) |
| MITRE CWE | CWE-116, Improper encoding or escaping of output |
Bibliography
| [ISO/IEC 646-1991] | "ISO 7-Bit Coded Character Set for Information Interchange" |
| [ISO/IEC 9899:2011] | Subclause 5.2.1, "Character Sets" |
| [Kuhn 2006] | "UTF-8 and Unicode FAQ for UNIX/Linux" |
| [VU#439395] | |
| [Wheeler 2003 | Section 5.4, "File Names" |
...
...