Some functions return a pointer to an object that cannot be modified without causing undefined behavior. These functions include getenv()
, setlocale()
, localeconv()
, asctime()
, and strerror()
. In such cases, the function call results must be treated as being const
-qualified.
The C Standard, 7.24.4.6, paragraph 4 [ISO/IEC 9899:2024], defines getenv()
as follows:
The
getenv
function returns a pointer to a string associated with the matched list member. The string pointed to shall not be modified by the program, but may be overwritten by a subsequent call to thegetenv
function. If the specified name cannot be found, a null pointer is returned.
If the string returned by getenv()
must be altered, a local copy should be created. Altering the string returned by getenv()
is undefined behavior. (See undefined behavior 184.)
Similarly, subclause 7.11.1.1, paragraph 8 [ISO/IEC 9899:2024], defines setlocale()
as follows:
The pointer to string returned by the
setlocale
function is such that a subsequent call with that string value and its associated category will restore that part of the program's locale. The string pointed to shall not be modified by the program, but may be overwritten by a subsequent call to thesetlocale
function.
And subclause 7.11.2.1, paragraph 8 [ISO/IEC 9899:2024], defines localeconv()
as follows:
The
localeconv
function returns a pointer to the filled-in object. The structure pointed to by the return value shall not be modified by the program, but may be overwritten by a subsequent call to thelocaleconv
function. In addition, calls to thesetlocale
function with categoriesLC_ALL
,LC_MONETARY
, orLC_NUMERIC
may overwrite the contents of the structure.
Altering the string returned by setlocale()
or the structure returned by localeconv()
are undefined behaviors. (See undefined behaviors 120 and 121.) Furthermore, the C Standard imposes no requirements on the contents of the string by setlocale()
. Consequently, no assumptions can be made as to the string's internal contents or structure.
Finally, subclause 7.26.6.3, paragraph 4 [ISO/IEC 9899:2024], states
The
strerror
function returns a pointer to the string, the contents of which are locale-specific. The array pointed to shall not be modified by the program. The behavior is undefined if the returned value is used after a subsequent call to thestrerror
function, or after the thread which called the function to obtain the returned value has exited.
Altering the string returned by strerror()
is undefined behavior. (See undefined behavior 184.)
Noncompliant Code Example (getenv()
)
This noncompliant code example modifies the string returned by getenv()
by replacing all double quotation marks ("
) with underscores (_
):
#include <stdlib.h> void trstr(char *c_str, char orig, char rep) { while (*c_str != '\0') { if (*c_str == orig) { *c_str = rep; } ++c_str; } } void func(void) { char *env = getenv("TEST_ENV"); if (env == NULL) { /* Handle error */ } trstr(env,'"', '_'); }
Compliant Solution (getenv()
) (Environment Not Modified)
If the programmer does not intend to modify the environment, this compliant solution demonstrates how to modify a copy of the return value:
#include <stdlib.h> #include <string.h> void trstr(char *c_str, char orig, char rep) { while (*c_str != '\0') { if (*c_str == orig) { *c_str = rep; } ++c_str; } } void func(void) { const char *env; char *copy_of_env; env = getenv("TEST_ENV"); if (env == NULL) { /* Handle error */ } copy_of_env = (char *)malloc(strlen(env) + 1); if (copy_of_env == NULL) { /* Handle error */ } strcpy(copy_of_env, env); trstr(copy_of_env,'"', '_'); /* ... */ free(copy_of_env); }
Compliant Solution (getenv()
) (Modifying the Environment in POSIX)
If the programmer's intent is to modify the environment, this compliant solution, which saves the altered string back into the environment by using the POSIX setenv()
and strdup()
functions, can be used:
#include <stdlib.h> #include <string.h> void trstr(char *c_str, char orig, char rep) { while (*c_str != '\0') { if (*c_str == orig) { *c_str = rep; } ++c_str; } } void func(void) { const char *env; char *copy_of_env; env = getenv("TEST_ENV"); if (env == NULL) { /* Handle error */ } copy_of_env = strdup(env); if (copy_of_env == NULL) { /* Handle error */ } trstr(copy_of_env,'"', '_'); if (setenv("TEST_ENV", copy_of_env, 1) != 0) { /* Handle error */ } /* ... */ free(copy_of_env); }
Noncompliant Code Example (localeconv()
)
In this noncompliant example, the object returned by localeconv()
is directly modified:
#include <locale.h> void f2(void) { struct lconv *conv = localeconv(); if ('\0' == conv->decimal_point[0]) { conv->decimal_point = "."; } }
Compliant Solution (localeconv()
) (Copy)
This compliant solution modifies a copy of the object returned by localeconv()
:
#include <locale.h> #include <stdlib.h> #include <string.h> void f2(void) { const struct lconv *conv = localeconv(); if (conv == NULL) { /* Handle error */ } struct lconv *copy_of_conv = (struct lconv *)malloc( sizeof(struct lconv)); if (copy_of_conv == NULL) { /* Handle error */ } memcpy(copy_of_conv, conv, sizeof(struct lconv)); if ('\0' == copy_of_conv->decimal_point[0]) { copy_of_conv->decimal_point = "."; } /* ... */ free(copy_of_conv); }
Risk Assessment
Modifying the object pointed to by the return value of getenv()
, setlocale()
, localeconv()
, asctime()
, or strerror()
is undefined behavior. Even if the modification succeeds, the modified object can be overwritten by a subsequent call to the same function.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
ENV30-C | Low | Probable | Medium | P4 | L3 |
Automated Detection
Tool | Version | Checker | Description |
---|---|---|---|
Astrée | 24.04 | stdlib-const-pointer-assign | Partially checked |
Axivion Bauhaus Suite | 7.2.0 | CertC-ENV30 | |
CodeSonar | 8.1p0 | BADFUNC.GETENV | Use of getenv |
Compass/ROSE | Can detect violations of this rule. In particular, it ensures that the result of | ||
Cppcheck Premium | 24.9.0 | premium-cert-env30-c | Fully implemented |
Helix QAC | 2024.3 | C1492, C1493, C1494 DF4751, DF4752, DF4753 | |
Klocwork | 2024.3 | MISRA.STDLIB.CTYPE.RANGE.2012_AMD1 | |
LDRA tool suite | 9.7.1 | 107 D | Partially Implemented |
Parasoft C/C++test | 2023.1 | CERT_C-ENV30-a | The pointers returned by the Standard Library functions 'localeconv', 'getenv', 'setlocale' or, 'strerror' shall only be used as if they have pointer to const-qualified type |
Polyspace Bug Finder | R2024a | Checks for modification of internal buffer returned from nonreentrant standard function (rule fully covered) | |
PVS-Studio | 7.33 | V675 | |
RuleChecker | 24.04 | stdlib-const-pointer-assign | Partially checked |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
Key here (explains table format and definitions)
Taxonomy | Taxonomy item | Relationship |
---|---|---|
ISO/IEC TS 17961:2013 | Modifying the string returned by getenv , localeconv , setlocale , and strerror [libmod] | Prior to 2018-01-12: CERT: Unspecified Relationship |
Bibliography
[IEEE Std 1003.1:2013] | XSH, System Interfaces, getenv XSH, System Interfaces, setlocale XSH, System Interfaces, localeconv |
[ISO/IEC 9899:2024] | 7.11.1.1, "The setlocale Function"7.11.2.1, "The localeconv Function"7.24.4.6, "The getenv Function"7.26.6.3, "The strerror Function" |
12 Comments
Jonathan Leffler
In most Unix-ish implementations, modifying the return from
getenv()
will modify the actual environment. If that's the required effect, we need to illustrate usingputenv()
with caveats about where it is supported.Douglas A. Gwyn
In the compliant examples, env[0]==0 should be treated as an error condition, since storing 'a' there could leave the string unterminated.
Generally, modifying the environment should be discouraged (except for sanitizing before spawning a child process). For one thing, on some systems it affects parent processes and on others it doesn't.
David Svoboda
Theoretically shouldn't
getenv()
return aconst char*
? Perhaps this rule should be rephrased that only aconst char*
should hold the result ofgetenv()
?Alex Volkovitsky
I like the
const char *
idea a lot, it would also make validation MUCH easier, should I go ahead and try to merge this into the article?Geoff Clare
If the additions to this page relating to setlocale() and localeconv() are going to stay, then the page needs more changes. For example:
Also the setlocale() compliant solution may follow the secure coding rules, but it is not portable. The content of the string returned by setlocale() is unspecified; applications cannot assume it contains a locale name.
Robert Seacord (Manager)
I addressed most of your comments. I also added the
strerror()
function which has similar characteristics. Still need to look at portability of thesetlocale()
compliant solution. A further problem is where this rule now belongs because the environment section is probably not the right place anymore. I'm sort of thinking the expressions section, because that is a pretty good catch all section. This might be best suited for a "Library" section, if we had one.Geoff Clare
Yes, you fixed the major problems (except the setlocale() portability one). I made a few more small fixes, including changing strtr to trstr since strtr is in the namespace reserved by the C Standard.
David Svoboda
C99, section 7.11.1 (setlocale()) says:
Furthermore, both the
setlocale()
NCCE & CS make no assumptions about the string returned; they should work no matter what its contents. So I stipulate that both the NCCE & CS are fully C99-compliant & portable.Geoff Clare
The C99 text you quote doesn't mean that setlocale() returns the string you passed to it. If it did, then calling setlocale(category, "") would return an empty string.
C99 says (para 8):
This, to me, is a clear warning that the only thing applications can legitimately do with the string is pass it to a subsequent setlocale() call; they shouldn't try to interpret the contents of the string. Also, if the call to setlocale(LC_ALL, "") sets two or more categories to different locales then those multiple locale names need to be encoded in the returned string somehow. The way this is done is implementation-specific.
Moving on:
They assume something about what a "." character in the string means. This may be reasonably safe, but they also assume there will be at most one "." character. If the call to setlocale(LC_ALL, "") sets two or more categories to different locales then there could be more than one "." in the string.
David Svoboda
Granted.
Hmm. Clearly you can't make a NCCE w/o making some assumptions about the string's contents. I don't know much about localization, but I presume that other platforms or standards provide some details about the contents of the string returned by setlocale(). This means you could make a compliant solution that copies the string and modifies it; it would just be non-portable.
The simplest solution is to leave the code as is, but add your caveat about multiple .'s. Alternately we could make a different (nonportable) modification...suggestions?
Geoff Clare
Indeed.
Usually a NCCE tries to achieve something sensible, only it goes about it in an insecure way. The problem with the setlocale() NCCE is that there is nothing sensible that can be achieved by modifying the string returned by setlocale().
My suggestion would be just to remove the setlocale() examples, or perhaps replace them with ones based on one of the other functions (if you can think of something sensible that can be achieved for one of them).
David Svoboda
I've removed the setlocale() examples. We should add a NCCE/CS pair based on strerror() later.