Environment Variable Attack#

Task 1: Manipulating Environment Variables#

Listing the environment variables can be done with the env or printenv bash commands, like so:

Setting or modifying an environment variable can be done with the export command, and removing one can be done with the unset command, like so:

Task 2: Passing Environment Variables from Parent Process to Child Process#

Using the code given in myprintenv.c, which is as follows:

1
#include <unistd.h>
2
#include <stdio.h>
3
#include <stdlib.h>
4

5
extern char **environ;
6

7
void printenv()
8
{
9
  int i = 0;
10
  while (environ[i] != NULL) {
11
     printf("%s\n", environ[i]);
12
     i++;
13
  }
14
}
15

16
void main()
17
{
18
  pid_t childPid;
19
  switch(childPid = fork()) {
20
    case 0:  /* child process */
21
      printenv();
22
      exit(0);
23
    default:  /* parent process */
24
      // printenv();
25
      exit(0);
26
  }
27
}

Then, compiling the code and running it gives the following output:

We can see that this even includes environment variable that I’ve set:

From there, we modify the code by commenting out the printenv() command in case 0, and uncommenting the printenv() in case 1, then compiling and running the code again.

The output is as follows:

After running again and piping the results into out1 and out2 respectivly, we can use the diff command, with the -s flag to tell us if these files are identical.

From the output we can see that the files are identical.

This means that both the parent process and the child process that forked off share the same environment variables.

If there was a vunerable parent program where an attacker could change the PATH environment variable (perhaps by exploiting a buffer overflow or similar attack), and a child process that ran some bash command like dir, then an attacker could change the PATH variable in the parent process to point to a directory with a malicious program called dir.

This would result in the child process inheriting the PATH env and executing the malicious program unintentionally.

This would be far less challenging than trying to cram an entire program into a buffer overflow attack.

Task 5: Environment Variable and Set-UID Programs#

We create the program env.c with the following code:

1
#include <stdio.h>
2
#include <stdlib.h>
3
extern char **environ;
4
int main()
5
{
6
  int i = 0;
7
  while (environ[i] != NULL) {
8
    printf("%s\n", environ[i]);
9
    i++;
10
  }
11
}

This program prints out all environment variables.

From there we compile the program with this command:

1
gcc env.c -o t5

and modify it with chown and chmod to make it a Set-UID program with root as it’s owner.

Then we change several environment variables as follows:

Now we run the program, getting the output:

Clearly an output of environment variables, however, notice the following:

From this we can see that some environment variables are passed from the user’s envs to a Set-UID process, but not all of them.

Specifically LD_LIBRARY_PATH was not passed to the program.

Task 6: The PATH Environment Variable and Set-UID Programs#

We create a program called just_ls.c with the following code:

1
int main()
2
{
3
  system("ls");
4
  return 0;
5
}

From there we compile it, change it’s owner to root, and make it a Set-UID program:

Running it gives the result:

Then, by modifying the PATH env, we can change where the system(ls) looks for the ls program.

We modify the path so it looks in the home/seed directory first; our user home directory.

Then we create a ‘malicious’ program and compile it into an executable called ls and drop it in the home/seed directory.

The malicious program has the following code:

1
#include <stdio.h>
2
#include <unistd.h>
3
int main()
4
{
5
  if(geteuid()){
6
    printf("Nothing to see here, just a normal user program\n");
7
  } else {
8
    printf("You got hacked!!!\n");
9
  }
10
  return 0;
11
}

The program will display “You got hacked!!!” if the effective user id is 0, AKA root.

Then when we execute our just_ls program and the output is now as follows:

This means that we were able to execute a custom program by changing the PATH env.

Additionally, since just_ls was a root owned Set-UID program, the effective permissions for our malicious program were high enough to ‘hack’ the user.