Environment variables attack

What is environment variable

Environment variables are set of dynamic name-value pairs stored inside a process, they affect a process's behaviour. For example, when a process is executed by a shell process, it uses an environment variable named PATH to find where a program is (if the full path of the program is not specified).

But where do a process get its environment variable? The answers is a process initially get its environment variables through one of two way:

• If a process is a new one (fork in C), the child's process inherits all environment variables of parent process since its memory is duplicated from parent's memory.
• If a process run a new program itself (execve in C), it overwirtes all of its current memory, this leads to all of its previous environment variables is lost, unless it passes its environment when invoking new process.

How do the attack happen?

Overview

In an attack, environment variable is usually used as input of a set-uid program. What makes environment variables danger is that in most of the time, the developers of the program are not aware of the usage of its. This leads to the leak of sanitizing these inputs, which may affect the behavior of a program.

We can categorize the attack surface of environment variables into

$2$ main categories:

• Linker: A linker is used to find the external library functions used by a program. In most operating systems the linker use environment variables to find where the libraries are. By that, malicious user can make use of this and cause a priviledged program to "find" their malicious libraries first instead of the developer's intended library.
• Application: in this surfaces, problem comes from the wrong in implementation of application. Those wrong are divided into
  $3$ type: library, external program and application itself.
  • Library: some external libraries can contain library vulnerability since they are not developed for privileged programs, and therefore may not sanitize the values of environment variables well. This can leads to attack in the environment variables that these external functions using.
  • External program: When a program invoke external programs for certain functionalities, such as sending emails, processing data, etc, its code runs with the calling process's privilege. The external program may use some environment variables that are not used by the caller program and therefore expanded the attack surface.
  • Application code: when a program use environment variables itself, misunderstanding how the variables get into program may cause to incorrect sanitization of it.

Linker attack: the LD_PRELOAD environment variable

During the linking stage, the Linux dynamic linker searches some default folders for the library function used by the program. User can specify additional search places using the LD_PRELOAD and LD_LIBRARY_PATH environment variables.

The dynamic linker will search for shared libraries by path in the LD_PRELOAD variable first, then if not all functions are found, it will then search by path in the LD_LIBRARY_PATH. Since those two variable can be modified by user, this open an opportunity for attacker to control the outcome of the dynamic linking resources.

Now let's move to an example of this attack, assume that we have the following function:

/* mytest.c */
#include <unistd.h>

int main() {
    sleep(1);
    return 0;
}

When we compile the program, by default the sleep() function is dynamically liked with libc.so library of linux, the program will sleep for one second as expected.

$ gcc mytest.c -o mytest
$ ./mytest

However, if we have an program like this:

/* mytest.c */
#include <stdio.h>

void sleep(int s) {
    printf("I am not sleeping!\n");
}

Then we can make the sleep() function in mytest point to our sleep() function instead of the original function of libc.so by do these step:

$ gcc -c sleep.c
$ gcc -shared -o libmylib.so.1.0.1 sleep.o
$ export LD_PRELOAD=./libmylib.so.1.0.1
$ ./mytest
I am not sleeping!

In the above commands, we first compile the sleep.c without linking. Next, we create a shared library named libmylib.so.1.0.1 from the compiled file. finally, we modify the LD_PRELOAD variable for prior our library when searching for function. The result is that the sleep() function is overwrited by our malicious function.

But is this technique work with Set-UID program? The answer is NO, since the dynamic linker ld.so has a countermeasure ignoring the LD_PRELOAD variable as well as LD_LIBRARY_PATH variable when real and effective user ID differ. However, if we have use custom environment variable in our code, like LD_MYOWN, then the dynamic linker will not ignore this and we will have to sanitize it by ourself, otherwise attacker can make use of it.

External program attack: the PATH environment variable

Shell program's behaviour are affected by many environment variables. The most common one is the PATH environment variable. Consider the following set-uid program:

/* The vulnerable program (vul.c) */ 
#include <stdlib .h> 
int main() {
    system("ls");
}

We can compile and set it as set-uid program by do following commands:

$ gcc -o vul vul.c
$ sudo chown root vul
$ sudo chmod 4755 vul

In the above code, the developer intends to run the ls command to list all the file and folder of current path. But the question here is: how does the program can find the ls program? The answer is it will look for the ls in paths given by PATH environment variable:

$ env | grep PATH
PATH=/home/seed/Downloads/...

By that, it will find the ls program at /usr/bin/ls. However, user can easily change the PATH environment variable by the export command. Now assume that we have the following program located at /malicious folder:

/* our malicious "ls" program*/ 
#include <stdlib.h> 
int main() 
{
    system( "/bin/sh");
}

What if we compile this program as ls and modify the PATH environment variable so that it will find the program in our folder first?

$ gcc malicious.c -o ls
$ export PATH = /malicious:$PATH

This will causes the program to find ls program as /malicious/ls program, which is an malicious program. Since our vul program is set-uid, the ls program will be invoked with root permission, and by that the system( "/bin/sh") will invoke a privileged shell, which is very dangerous:

$./vul
#

However, a modern bash shell has a countermeasure to downgrade the invoked shell of set-uid program. As a result, this attack is only works on outdated machine.

Countermeasures

To reduce the vulnerability of environment variables, we have some solution:

• Carefull use environment: Never trust the content of environment variables, neither explicit nor implicitm, always remove or sanitize them before use in a privileged program.
• Use service approach: different from set-uid approach, in the service approach, normal users have to request a privileged service to start a program, so environment variables are passed by the service, not the user.