GLEXEC-2009-0005

The operator of glexec could configure glexec in a way that would unknowingly allow a root exploit similar to those described in reports GLEXEC-2009-0002 and GLEXEC-2009-0004.

local user

This vulnerability requires local access to the machine with the ability to execute glexec. In addition the user must be in the white list of accounts permitted to use glexec.

high

To exploit this vulnerability requires that operator introduce a certain setting in the glexec configuration file. If this is done low effort is required by an attacker.

high

The impact of this vulnerability is that the attacker gains root access on the host.

The attacks described in GLEXEC-2009-0002 and GLEXEC-2009-0004, can be enabled by the operator of glexec allowing environment variables beginning with LCAS_ and LCMAPS_. The glexec configuration file should be owned by root, so the operator would have to enable these changes. These variable can be allowed by listing them in the preserve_env_variables option in the glexec configuration file. The values specified are a prefix of environment variables to allow unless they end with an equal sign in which case exactly the environment variable with the name before the equal sign is allowed.

Although it is unlikely that an operator would add the following line to the glexec configuration file to enable these dangerous environment variables, it is still possible:

    preserve_env_variables = LCAS_, LCMAPS_
  

A more likely scenario is that the operator would like users to be able to specify locale properties through the use of the standard environment variables: LC_ALL, LC_CTYPE, LC_COLLATE, LC_MONETARY, LC_NUMERIC, LC_TIME, and LC_MESSAGES. If the operator included the following line in the glexec configuration file to allow these locale variables, it also allows the use of variables starting with LCAS_ and LCMAPS.

    preserve_env_variables = LC
  

operational issue
improper data validation

This vulnerability is caused by improperly the operator of glexec to too easily allow a user to specify environment variables that affect code run with root privileges. These environment variable allow an attacker to gain root access.

An easy solution to this problem would be to create a list (dangerous_env_lst) enumerating all the dangerous environment variables used by glexec and its libraries. This list needs to include variables with a prefix of LCAS_ and LCMAPS_. There may be other names that are dangerous that can be determined by auditing glexec and its libraries for their use of environment variables. Then code needs to be added to the function glexed_clean_env after the checks for the environment variables to preserve. This code needs to check that the environment variable is not in the dangerous_env_lst list. The code should be similar to the following:

    if (preserve && dangerous_env_vars) {
	const char** dangerPtr;
        for (dangerPtr = dangerous_env_var; *dangerPtr; dangerPtr++) {
            if (strncmp(*ep, *dangerPtr, strlen(*dangerPtr))==0) {
                preserve = 0;
                break;
            }
        }
    }
  

The better long term solution would be for glexec, LCAS, and LCMAPS to not use the environment as a form of global variables. Environment variables have historically caused security problems in system libraries especially when used in setuid programs (such as glexec). System libraries no longer use environment variables that can affect security when used in a setuid program, such as the environment variables used to control the dynamic linker and memory allocator. Since environment variables are implicit in the API to libraries, developers tend to not think about these hidden parameters they are part of the interface and subsequently tend not to control their values as well as they do for explicitly passed parameters.

This research funded in part by National Science Foundation grant OCI-0844219, NATO grant CLG 983049, and National Science Foundation grants CNS-0627501 and CNS-0716460.