Some environments provide environment pointers that are valid when main()
is called but may be invalided by operations that modify the environment.
Subclause J.5.1 of the C Standard [ISO/IEC 9899:2011] states:
In a hosted environment, the main function receives a third argument,
char *envp[]
, that points to a null-terminated array of pointers tochar
, each of which points to a string that provides information about the environment for this execution of the program.
Consequently, under a hosted environment, it is possible to access the environment through a modified form of main()
:
Code Block |
---|
main(int argc, char *argv[], char *envp[]) |
However, modifying the environment by any means may cause the environment memory to be reallocated with the result that envp
now references an incorrect location.
For example, when compiled with GCC 4.8.1 and run on a 32-bit Intel GNU/Linux machine, the following code,
Code Block |
---|
#include <stdio.h> #include <stdlib.h> extern char **environ; int main(int argc, const char *argv[], const char *envp[]) { printf("environ: %p\n", environ); printf("envp: %p\n", envp); setenv("MY_NEW_VAR", "new_value", 1); puts("--Added MY_NEW_VAR--"); printf("environ: %p\n", environ); printf("envp: %p\n", envp); return 0; } |
yields
Code Block |
---|
% ./envp-environ environ: 0xbf8656ec envp: 0xbf8656ec --Added MY_NEW_VAR-- environ: 0x804a008 envp: 0xbf8656ec |
It is evident from these results that the environment has been relocated as a result of the call to setenv()
.
Noncompliant Code Example (POSIX)
After a call to the POSIX setenv()
function or to another function that modifies the environment, the envp
pointer may no longer reference the environment. POSIX [Open Group 2004] states that
unanticipated results may occur if
setenv()
changes the external variableenviron
. In particular, if the optionalenvp
argument tomain()
is present, it is not changed, and as a result may point to an obsolete copy of the environment (as may any other copy ofenviron
).
This noncompliant code example accesses the envp
pointer after calling setenv()
:
Code Block | ||||
---|---|---|---|---|
| ||||
#include <stdio.h> #include <stdlib.h> int main(int argc, const char *argv[], const char *envp[]) { if (setenv("MY_NEW_VAR", "new_value", 1) != 0) { /* Handle error */ } if (envp != NULL) { for (size_t i = 0; envp[i] != NULL; ++i) { if (puts(envp[i]) == EOF) { /* Handle error */ } } } return 0; } |
Because envp
may no longer point to the current environment, this program has undefined behavior.
Compliant Solution (POSIX)
Use environ
in place of envp
when defined:
Code Block | ||||
---|---|---|---|---|
| ||||
#include <stdio.h> #include <stdlib.h> extern char **environ; int main(int argc, const char *argv[]) { if (setenv("MY_NEW_VAR", "new_value", 1) != 0) { /* Handle error */ } if (environ != NULL) { for (size_t i = 0; environ[i] != NULL; ++i) { if (puts(environ[i]) == EOF) { /* Handle error */ } } } return 0; } |
Noncompliant Code Example (Windows)
After a call to the Windows _putenv_s()
function or to another function that modifies the environment, the envp
pointer may no longer reference the environment.
According to the Visual C++ reference [MSDN],
The environment block passed to
main
andwmain
is a "frozen" copy of the current environment. If you subsequently change the environment via a call to_putenv
or_wputenv
, the current environment (as returned bygetenv
/_wgetenv
and the_environ
/_wenviron
variable) will change, but the block pointed to byenvp
will not change.
This noncompliant code example accesses the envp
pointer after calling _putenvs()
:
Code Block | ||||
---|---|---|---|---|
| ||||
#include <stdio.h> #include <stdlib.h> int main(int argc, const char *argv[], const char *envp[]) { if (_putenv_s("MY_NEW_VAR", "new_value") != 0) { /* Handle error */ } if (envp != NULL) { for (size_t i = 0; envp[i] != NULL; ++i) { if (puts(envp[i]) == EOF) { /* Handle error */ } } } return 0; } |
Because envp
no longer points to the current environment, this program fails to print the value of MY_NEW_VAR
.
Compliant Solution (Windows)
Use _environ
in place of envp
when defined:
Code Block | ||||
---|---|---|---|---|
| ||||
#include <stdio.h> #include <stdlib.h> _CRTIMP extern char **_environ; int main(int argc, const char *argv[]) { size_t i; if (_putenv_s("MY_NEW_VAR", "new_value") != 0) { /* Handle error */ } if (_environ != NULL) { for (i = 0; _environ[i] != NULL; ++i) { if (puts(_environ[i]) == EOF) { /* Handle error */ } } } return 0; } |
Compliant Solution
If you have a great deal of unsafe envp
code, you can save time in your remediation by replacing
Code Block |
---|
int main(int argc, char *argv[], char *envp[]) { /* ... */ } |
with
Code Block | ||||
---|---|---|---|---|
| ||||
#if defined (_POSIX_) || defined (__USE_POSIX) extern char **environ; #define envp environ #elif defined(_WIN32) _CRTIMP extern char **_environ; #define envp _environ #endif int main(int argc, char *argv[]) { /* ... */ } |
Risk Assessment
Using the envp
environment pointer after the environment has been modified can result in undefined behavior.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
ENV31-C | Low | Probable | Medium | P4 | L3 |
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
|
|
| |||||||
PRQA QA-C |
| 0601 (E) | Fully implemented |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
CERT C++ Secure Coding Standard | ENV31-CPP. Do not rely on an environment pointer following an operation that may invalidate it |
Bibliography
[ISO/IEC 9899:2011] | Subclause J.5.1, "Environment Arguments" |
[MSDN] | getenv, _wgetenv _environ, _wenviron _putenv_s, _wputenv_s |
[Open Group 2004] | setenv() |