Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Updated references from C11->C23

Some implementations provide a nonportable environment pointer that is valid when main() is called but may be invalidated by operations that modify the environment.

The C Standard, J.5.2 [ISO/IEC 9899:2024], states

In a hosted environment, the main function receives a third argument, char *envp[], that points to a null-terminated array of pointers to char, each of which points to a string that provides information about the environment for this execution of the program (5.1.2.3.2).

Consequently, under a hosted environment supporting this common extension, 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(). The external variable environ is updated to refer to the current environment; the envp parameter is not.

An environment pointer may also become invalidated by subsequent calls to getenv(). (See ENV34-C. Do not store pointers returned by certain functions for more information.)

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 current environment. The Portable Operating System Interface (POSIX®), Base Specifications, Issue 7 [IEEE Std 1003.1:2013], states

Unanticipated results may occur if setenv() changes the external variable environ. In particular, if the optional envp argument to main() is present, it is not changed, and thus may point to an obsolete copy of the environment (as may any other copy of environ).

This noncompliant code example accesses the envp pointer after calling setenv():

Code Block
bgColor#ffcccc
langc
#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
Wiki Markup
If an environment variable might have changed during program execution, get a fresh copy using {{getenv()}}. If you rely on your old variable, you could be left with incorrect data or a dangling pointer.

h2. Non-Compliant Coding Example

After a call to {{setenv()}}, environment pointers to the old value and copies of the old value will be incorrect.
{code:bgColor=#ccffcc}
char *temp;
char *copy;

if ((temp = getenv("TEST_ENV")) != NULL) {
  copy = malloc(strlen(temp) + 1);
  if (copy != NULL) {
    for strcpy(copy, temp);
  }
  else {
    /* handle error condition */
  }
}
/* ...program code... */
setenv("TEST_ENV", var, 1);
/* ...program code... */


printf("TEST_ENV: %s\n", temp);
printf("TEST_ENV: %s\n", copy);
{code}
Neither of the print statements will be correct.

h2. Compliant Solution

You should always fetch fresh copies of environment variables, especially if you know that a value has changed.
{code:bgColor=#ccccff}
char \*temp;
char \*copy;

if ((temp = getenv("TEST_ENV")) \!= NULL) {
copy = malloc(strlen(temp) + 1);
if (copy \!= NULL)
{     strcpy(copy, temp);   }
else {
/* handle error condition */
}
}
/* ...program code... */
setenv("TEST_ENV", var, 1);
/* ...program code... */

if ((temp = getenv("TEST_ENV")) != NULL) {
copy = malloc(strlen(temp) + 1);
if (copy(size_t i = 0; envp[i] != NULL; ++i) {
      puts(envp[i]);
    }
  }
  return 0;
}

Because envp may no longer point to the current environment, this program has unanticipated behavior.

Compliant Solution (POSIX)

Use environ in place of envp when defined:

Code Block
bgColor#ccccff
langc
#include <stdio.h>
#include <stdlib.h>
 
extern char **environ;

int main(void) {
  if (setenv("MY_NEW_VAR", "new_value", 1) != 0) {
    /* Handle error */
  }
  if (environ != NULL) {
    for (size_t i = 0; environ[i] != NULL; ++i) {
      puts(environ[i]);
    }
  }
  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 and wmain 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 by getenv / _wgetenv and the _environ / _wenviron variable) will change, but the block pointed to by envp will not change.

This noncompliant code example accesses the envp pointer after calling _putenv_s():

Code Block
bgColor#ffcccc
langc
#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) {
      puts(envp[i]);
    }
  }
  return 0;
}

Because envp no longer points to the current environment, this program has unanticipated behavior.

Compliant Solution (Windows)

This compliant solution uses the _environ variable in place of envp:

Code Block
bgColor#ccccff
langc
#include <stdio.h>
#include <stdlib.h>
 
_CRTIMP extern char **_environ;

int main(int argc, const char *argv[]) {
  if (_putenv_s("MY_NEW_VAR", "new_value") != 0) {
    /* Handle error */
  }
  if (_environ != NULL) {
    strcpy(copy, temp);  }
}
else
{     /* handle error condition */for (size_t i = 0; _environ[i] != NULL; ++i) {
      puts(_environ[i]);
    }
  }
printf("TEST_ENV: %s\n", temp);
printf("TEST_ENV: %s\n", copy);
This will provide us with the current value of the environment variable.

h2. Risk Assessment

The program would not be using current environment values, causing unexpected results.
|| Rule || Severity || Likelihood || Remediation Cost || Priority || Level ||
| ENV31-C | *1* (low) | *1* (low) | *3* (low) | {color:green}{*}P3{*}{color} | {color:green}{*}L3{*}{color} |

h2. References

\[[ISO/IEC 9899-1999:TC2|AA. C References#ISO/IEC 9899-1999TC]\] Section 7.20.4, "Communication with the environment"return 0;
}

Compliant Solution

This compliant solution can reduce remediation time when a large amount of noncompliant envp code exists. It replaces

Code Block
int main(int argc, char *argv[], char *envp[]) {
  /* ... */
}

with

Code Block
bgColor#ccccff
langc
#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[]) {
  /* ... */
}

This compliant solution may need to be extended to support other implementations that support forms of the external variable environ.

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

Astrée
Include Page
Astrée_V
Astrée_V
 Supported
Compass/ROSE




Cppcheck Premium
24.9.0
premium-cert-env31-c

Fully implemented

Helix QAC

Include Page
Helix QAC_V
Helix QAC_V

DF4991, DF4992, DF4993


LDRA tool suite
Include Page
LDRA_V
LDRA_V
118 SFully Implemented
Parasoft C/C++test

Include Page
Parasoft_V
Parasoft_V

CERT_C-ENV31-a

Do not rely on an environment pointer following an operation that may invalidate it

Polyspace Bug Finder

Include Page
Polyspace Bug Finder_V
Polyspace Bug Finder_V

CERT C: Rule ENV31-CChecks for environment pointer invalidated by previous operation (rule fully covered)

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

CERT CVOID ENV31-CPP. Do not rely on an environment pointer following an operation that may invalidate itPrior to 2018-01-12: CERT: Unspecified Relationship

Bibliography

[IEEE Std 1003.1:2013]XSH, System Interfaces, setenv
[ISO/IEC 9899:2024]J.5.2, "Environment Arguments"
[MSDN]_environ, _wenviron,
getenv, _wgetenv,
_putenv_s, _wputenv_s


...

Image Added Image Added Image Added