This is an extension of recommendation:
The type of a narrow string literal is an array of char
, and the type of a wide string literal is an array of wchar_t
. However, string literals (of both types) are notionally constant and should consequently be protected by const
qualification. This recommendation is a specialization of DCL00-C. Const-qualify immutable objects and also supports STR30-C. Do not attempt to modify string literalsSince string literals are constant, they should only be assigned to constant pointers as indicated below.
Adding const
qualification may propagate through a program; as const
qualifiers are added, still more become necessary. This phenomenon is sometimes called const-poisoning. Const-poisoning can frequently lead to violations of EXP05-C. Do not cast away a const qualification. Although const
qualification is a good idea, the costs may outweigh the value in the remediation of existing code.
Noncompliant Code Example (Narrow String Literal)
In this noncompliant code example, the const
keyword has been omitted:
Code Block | ||||
---|---|---|---|---|
| ||||
char* c1 = "Hello"; // Bad: assigned to non-const char c2[] *c = "Hello"; // Bad: assigned to non-const char c3[6] = "Hello"; // Bad: assigned to non-const c1[3] = 'a'; // Undefined (but compiles) |
If a statement such as c[0] = 'C'
were placed following the declaration in the noncompliant code example, the code is likely to compile cleanly, but the result of the assignment would be undefined because string literals are considered constant.
Compliant Solution (Immutable Strings)
In this compliant solution, the characters referred to by the pointer c
are const
-qualified, meaning that any attempt to assign them to different values is an error:
Code Block | ||||
---|---|---|---|---|
| ||||
const char *c c1 = "Hello"; |
Compliant Solution (Mutable Strings)
In cases where the string is meant to be modified, use initialization instead of assignment. In this compliant solution, c
is a modifiable char
array that has been initialized using the contents of the corresponding string literal:
Code Block | ||||
---|---|---|---|---|
| ||||
char c[ // Good const char c2[] = "Hello"; // Good const char c3[6] = "Hello"; // Good //c1[3] = 'a'; would cause a compile error |
By assigning string literals to constant pointers the compiler will disallow you from modifying the contents directly.
Making code reverse compatible to fit this standard sometimes breaks functionality but this is a good recommendation to follow on new code. An example of a situation where implementing this would break prior code is if a string literal is assigned to a non-const pointer as in the following example
Before changing string literals to constant pointers
Code Block |
---|
char* CMUfullname = "Carnegie Mellon";
...
//take user input to determine string variable "school"
if(strcmp(school,"CMU"))
{
school=CMUfullname;
}
|
This prior code works fine as long as the contents of string pointer "school" are not modified if it is assigned "CMUfullname"
If one were to simply change the declaration of the string literal "CMUfullname" to const this would be the output
Code Block |
---|
const char* CMUfullname = "Carnegie Mellon";
...
//take user input to determine string variable "school"
...
if(strcmp(school,"CMU")==0)
{
school=CMUfullname;
}
|
This code will give a compiler warning since the assignment of "CMUfullname" to school is discarding the const qualifier. Any modifications to the contents of school if it is assigned a constant string literal will cause error conditions.
A compliant fix to this problem would be to copy the contents of "CMUfullname" to "school" but this involves the extra step of making sure school has the appropriate storage to hold it.
Code Block | ||
---|---|---|
| ||
const char* CMUfullname = "Carnegie Mellon";
...
//take user input to determine string variable "school"
...
if(strcmp(school,"CMU")==0)
{
strcpy(school,CMUfullname);
}
|
This example has shown that remedying this situation in legacy code is not necessarily simple.
Risk Assessment
Modifying string literals can lead to abnormal program termination and results in undefined behavior that can be used in denial-of-service attacks.
|
Consequently, a statement such as c[0] = 'C'
is valid and behaves as expected.
Noncompliant Code Example (Wide String Literal)
In this noncompliant code example, the const
keyword has been omitted:
Code Block | ||||
---|---|---|---|---|
| ||||
wchar_t *c = L"Hello";
|
If a statement such as c[0] = L'C'
were placed following this declaration, the code is likely to compile cleanly, but the result of the assignment would be undefined because string literals are considered constant.
Compliant Solution (Immutable Strings)
In this compliant solution, the characters referred to by the pointer c
are const
-qualified, meaning that any attempt to assign them to different values is an error:
Code Block | ||||
---|---|---|---|---|
| ||||
wchar_t const *c = L"Hello";
|
Compliant Solution (Mutable Strings)
In cases where the string is meant to be modified, use initialization instead of assignment. In this compliant solution, c
is a modifiable wchar_t
array that has been initialized using the contents of the corresponding string literal:
Code Block | ||||
---|---|---|---|---|
| ||||
wchar_t c[] = L"Hello";
|
Consequently, a statement such as c[0] = L'C'
is valid and behaves as expected.
Risk Assessment
Modifying string literals causes undefined behavior, resulting in abnormal program termination and denial-of-service vulnerabilities.
Recommendation |
---|
Severity | Likelihood | Remediation Cost | Priority | Level |
---|
STR05-C |
1 (low)
3 (likely)
2(medium)
P6
L2
References:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1993/N0389.asc;
Low | Unlikely | Low | P3 | L3 |
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Astrée |
| literal-assignment | Fully checked | ||||||
Axivion Bauhaus Suite |
| CertC-STR05 | |||||||
Clang |
| -Wwrite-strings | Not enabled by -Weverything | ||||||
CodeSonar |
| LANG.TYPE.NCS | Non-const string literal | ||||||
Compass/ROSE | |||||||||
| CC2.STR05 | Fully implemented | |||||||
GCC |
| -Wwrite-strings | |||||||
Helix QAC |
| C0752, C0753 | |||||||
Klocwork |
| MISRA.STRING_LITERAL.NON_CONST.2012 | |||||||
LDRA tool suite |
| 623 S | Fully implemented | ||||||
Parasoft C/C++test |
| CERT_C-STR05-a | A string literal shall not be modified | ||||||
PC-lint Plus |
| 1776 | Fully supported | ||||||
RuleChecker |
| literal-assignment | Fully checked |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Bibliography
[Corfield 1993] | |
[Lockheed Martin 2005] | AV Rule 151.1 |
...
\[Lockheed Martin 2005\] Lockheed Martin. Joint Strike Fighter Air Vehicle C+\+ Coding Standards for the System Development and Demonstration Program. Document Number 2RDU00001, Rev C. December 2005. AV Rule 151.1 Wiki Markup