Linux and Unix Secure Programming: Environment Variables

Linux and Unix Secure Programming: environment variables-general Linux technology-Linux programming and kernel information. For details, see the following. Environment Variable
By default, environment variables are inherited from the parent process of the process. However, when the program executes another program, the calling program can set the environment variable to any value. This is dangerous for the setuid/setgid program because the intruders can fully control the environment variables they get. Environment variables are inherited and can also be passed for use. Security programs may call some other programs without special measures, this will pass potentially dangerous environment variable values to the called program.

Some environment variables are dangerous.
Some environment variables are dangerous because many libraries and programs are controlled by environment variables in some implicit, fuzzy, or undisclosed ways. For example, sh and bash shell use the IFS Variable to determine which character is used to separate command line parameters. Because shell is executed by several underlying calls (such as system (3), popen (3), or back-tick operator in Perl, setting IFS to an unusual value will disrupt seemingly safe calls. This behavior is illustrated in bash and sh, but not noticeable. Many long-time users know IFS only because they know that IFS can be used to undermine security, rather than intentionally and frequently used. Worse, not all environment variables are documented, and even other programs can change and increase dangerous environment variables. Therefore, the only real solution (described below) is to select only the required environment variables and ignore other environment variables.

The storage format of environment variables is dangerous.
In general, programs should use standard access routines to access environment variables. For example, in C, getenv (3) should be used to obtain the value of the environment variable, and the POSIX standard routine putenv (3) or BSD extension setenv (3) should be used to set the value of the environment variable, use unsetenv (3) to clear environment variables. It must be noted that setenv (3) is also implemented in Linux ). But hackers are not so kind. Hackers can directly control the environment variable data zone passed to the program using execve (2. This may cause some dirty attacks. Only those who understand the essence of environment variables can understand these attacks. In Linux, you can read environ (5) to learn about the essence of environment variables. In short, environment variables are stored internally as a pointer to the character pointer array, which is stored in order and ended with a NULL pointer (so that you can know when the array ends ). Each pointer pointing to a character points to a string value ending with NIL in the form of "NAME = value" in sequence. This has several meanings. For example, the environment variable name cannot contain equal signs, and neither name nor value can contain NIL characters. However, this format has a very dangerous meaning, that is, it allows multiple entries to use the same variable name with different values (for example, SHELL has multiple values ). Although the typical shell command prohibits this, hackers who operate locally can use execve (2) to create such a situation.

The problem with this storage format (and setting method) is that the program may check a value (to see if it is valid) but actually uses another different value. In Linux, the glibc library of GNU tries to protect the program from this impact: When getenv of glibc 2.1 is implemented, the first matching entry is always obtained, setenv and putenv always set the first matching entry, while unsetenv actually clears all matching entry settings (congratulations to the GNU glibc implementer for implementing unsetenv !). However, some programs directly access the environment variables and traverse all the environment variables repeatedly. In this case, they may use the last matched entry instead of the first one. The result is that if the first matching entry is checked, but the last matching entry is used, hackers can bypass the protection routine.

Solution-extract and clear
For secure setuid/setgid programs, be careful to extract the short list of environment variables that need to be used as input (if needed. The entire environment should be cleared, and a group of necessary environment variables should be reset as the security value. If the next-level program is called, this is actually not a better way; because there is no feasible way to list "All dangerous values ". Even if the source code of each program called directly or indirectly is carefully reviewed, someone can add new undisclosed environment variables after you write the code, there may be an available environment variable.

The simple way to clear the environment is to set the global variable environ to NULL. The global variable environ is defined in. The C/C ++ user needs to # include this header file. This value needs to be processed before the thread is generated, but this is hardly a problem, because it needs to be processed at the beginning of program execution. Another way to clear the environment is to use the undisclosed function clearenv (). Clearenv () has a strange history; someone suggested defining it in POSIX.1, but somehow it didn't go standard. Despite this, POSIX.9 (Fortran 77 bound to POSIX) defines clearenv (), so it is semi-official. Clearenv () is defined, but before using # include to include it, you must determine that _ USE_MISC has # defined.

A path value that is almost certainly constantly added is a list of directories of a search program. The PATH should not include the current directory, which should be like "/bin: /usr/bin "is that simple. IFS (default value: \ t \ n) and TZ (Time Zone) are also set ). If IFS or TZ is not provided, Linux will not crash, but some Systems Based on System V may have problems without the TZ value, and it is rumored that some shells require the IFS value to be set. In Linux, see environ (5) for a list of common environment variables that may need to be set.

If you do need to provide values, first check these values (to ensure that these values match the valid value pattern and within a reasonable maximum length ). Ideally, some standard trusted files under/etc contain "standard security environment variable value", but there is no standard file defined for this purpose. Similarly, you may need to check the pam_env of the PAM module in systems with PAM modules.

If you use a language that does not allow you to directly reset the environment to write the setuid/setgid program, one way is to create a "package" program. The package Program sets the Environment Program as a security value and then calls other programs. Note: determine that the package program will actually execute the expected program; if it is an interpreter, determine that there will be no possible competition, this allows the interpreter to load another program that is different from the one that grants special setuid/setgid permissions.