SET-UID Program Vulnerability Experiment

First, the experimental description

Set-uid is an important security mechanism in UNIX systems. When a set-uid program runs, it is assumed to have the permissions of the owner. For example, if the owner of the program is root, then anyone who runs the program will get permission from the program owner. Set-uid allows us to do a lot of interesting things, but unfortunately, it is also the culprit of many bad things.

So the goal of this experiment is two points:

1. Appreciate the good aspects, understand why set-uid is needed, and how it is implemented.

2. Be aware of the bad aspects and understand its potential security issues.

Second. contents of the experiment

This is an exploratory experiment where your task is to "play the game" with the SET-UID mechanism in the Linux environment and you need to complete the next lab task in Linux:

2.1 Guess why "passwd", "Chsh", "Su", and "sudo" commands need set-uid mechanisms, and if they don't have these mechanisms, what happens if you're unfamiliar with these programs, you can call to read manuals to familiarize yourself with them, If you copy these commands into your own directory, these programs will not be SET-UID programs, run these copies of the program, and observe what will happen

From the above can be seen: Copy passwd to/tmp/, the permissions have changed (in the original directory suid bit is set), the copy does not have the ability to modify the password.

For "Chsh", "Su", and "sudo" commands, these programs are copied to the user directory, also no longer have root privileges.

2.2 Run the SET-UID program in a Linux environment while describing and interpreting your observations

2.2.1 Log in as root, copy the/bin/zsh to/TMP, and set the copy to the TMP directory zsh to Set-uid root, then log in as a normal user and run/tmp/zsh. Will you get root privileges? Please describe your results.

2.2.2 Copy/bin/bash to/tmp directory, while setting bash in/tmp to SET-UID root, then log in as normal user and run/tmp/bash. Will you get root privileges? Please describe your results.

Visible, the same operation, run copy of zsh can get root permission, and bash cannot.

2.3 From the above steps, it can be seen that/bin/bash has some kind of intrinsic protection mechanism to prevent the misuse of set-uid mechanism. To be able to experience the situation before this intrinsic protection mechanism occurs, we intend to use another shell program--/bin/zsh. In some Linux distributions (such as Redora and Ubuntu),/bin/sh is actually a symbolic link to/bin/bash. In order to use zsh, we need to link/bin/sh to/bin/zsh.

The following command will point the default shell to Zsh:

 
$sudo su
Password:
#cd /bin#rm sh#ln -s zsh sh

2.4 Setting of the PATH environment variable

Systems (const char * cmd) system call functions are embedded into a program to execute a command, System () calls/bin/sh to execute the shell program, and then the shell program executes the cmd command. However, it is very dangerous to call the shell in a set-uid program because the shell program's behavior can be affected by environment variables such as path, and these environment variables can be in the user's control. By controlling these variables, users with malicious intentions can control the behavior of the SET-UID program.

The following Set-uid program is used to execute the/BIN/LS command, and the programmer can use a relative path instead of an absolute path for the LS command.

 
intmain(){
   system("ls");
   return0;
}

2.4.1 Can you set this SET-UID program to run your own code instead of/bin/ls? If you can, does your code have root privileges? Describe and explain your observations.

can have root permission, copy/bin/sh to/tmp directory under Rename to LS (first make sure the SH symbol in the/bin/directory is linked to zsh instead of bash), set the environment variable path to the current directory/TMP, run the compiled program test. You can get root privileges:

2.4.2 Modify/bin/sh so that it returns to/bin/bash and repeat the above attack, can you still get root permission? Describe and explain your observations.

Visible Modify SH connection back to bash, run test program does not allow ordinary users to gain root privileges.

2.5 sytem () and Execve () are different

First make sure/bin/sh points to zsh

Background: Bob, who works for an audit agency, is investigating whether a company has fraud. For this purpose, he needs to read all the files on the UNIX system of the company; On the other hand, to protect the system's reliability, he cannot modify any of the files. To achieve this, the vince--system's Superuser wrote a set-root-uid program for him and gave Bob permission to execute it. This program requires Bob to shoot a file name on the command line and then run the/BIN/CAT command to display the file. Now that the program is running as root, it can display any file that Bob wants to see. However, since this program is not written, Vince is sure that Bob cannot modify any files with this program.

 
#include <string.h>#include <stdio.h>#include <stdlib.h>intmain(int argc, char *argv[]){
   char *v[3];
   if(argc < 2)
   {
   printf("Please type a file name.\n");
   return1;
   }
   v[0] = "/bin/cat"; v[1] = argv[1]; v[2] = 0;
  //Set q = 0 for Question a, and q = 1 for Question bint q = 0;
   if (q == 0)
   {
      char *command = malloc(strlen(v[0]) + strlen(v[1]) + 2);
      sprintf(command, "%s %s", v[0], v[1]);
      system(command);
  }
  elseexecve(v[0], v, 0);
  return0 ;
}

There are q=0 in the 2.5.1 program. The program invokes the command line using System (). This command security code? If you are Bob, can you compromise on the integrity of the system? Can you re-move a file that doesn't have permission to write to you?

This command is unsafe, and Bob may be tempted to read or modify some files that only the root user can run out of curiosity or personal interest. For example, in: File files only the root user has read and write permissions, but ordinary users by running the program, read and rename the file files:

2.5.2 If the q=1 is made, will the attack be effective? Please describe and explain your observations.

After modification to q=1, it will not be valid. The previous step is valid because the system () function calls/bin/sh, linked to Zsh, and then executes the MV File file_new command after executing the cat file file with root permission.

And when the Q=1, Execve () function will put file; MV file File_new is considered to be a file name and the system will prompt that it does not exist:

Ordinary users cannot rename file files through the SRU2 program.

2.6 Ld_preload Environment variables

In order to ensure that the SET-UID program is safe under the ld_preload environment, the dynamic linker ignores the environment variables, but under certain conditions is the exception, and in the following tasks we guess what these special conditions are.

1, let us establish a dynamic link library. Name the following program MYLIB.C, and put it in the/tmp directory. The sleep function is overloaded in the function library libc:

 
#include <stdio.h>voidsleep(int s){
    printf("I am not sleeping!\n");
}

2, we use the following command to compile the above program (note the difference between L and 1):

 
gcc -fPIC -g -c mylib.c

gcc -shared -Wl,-soname,libmylib.so.1 -o libmylib.so.1.0.1 mylib.o –lc

3, the following program named MYPROG.C, placed in the/tmp directory:

 
intmain(){
   sleep(1);
   return0;
}

Please run these programs under the conditions below and observe the results. Based on these observations, we tell you when the linker will ignore the LD_PRELOAD environment variable and explain why.

2.6.1 Myprog compiled into a normal user program under the ordinary user run

It can be seen that it uses the LD_PRELOAD environment variable to overload the Sleep function:

2.6.2 Myprog compiled into a set-uid root program to run under the ordinary user

In this case, ignore the LD_PRELOAD environment variable, do not overload the sleep function, and use the system's own sleep function:

2.6.3 The program that compiles myprog into a set-uid root runs under root

In this case, using the LD_PRELOAD environment variable, use the overloaded sleep function:

2.6.4 under a normal user to compile Myprog into a set-uid ordinary user program run under another ordinary user

In this case, the sleep function is not overloaded:

It can be seen from the above four cases: only the user's own program to run, will use the LD_PRELOAD environment variable, overload the Sleep function, otherwise ignore the LD_PRELOAD environment variable, do not overload the sleep function.

2.7 Elimination and cleanup privileges

To be more secure, SET-UID programs typically call the SETUID () system call function to permanently purge their root permissions. Sometimes, however, this is far from enough. Under root user, create a new empty file in the/tmp directory, zzz. Under root user name the following code test.c, put in the/tmp directory, compile the program, give the program root permissions. Under an ordinary user, run this program. Describe the situation you have observed,/TMP/ZZZ will this file be modified? Explain your observations.

Code:

 
#include <stdio.h>#include <stdlib.h>#include <sys/types.h>#include <sys/stat.h>#include <fcntl.h>voidmain(){
  int fd;
  //Assume that /tmp/zzz is an important system file,//and it is owned by root with permission 0644
  fd = open("/tmp/zzz", O_RDWR | O_APPEND);
  // Simulate the tasks conducted by the program
  sleep(1);
  // After the task, the root privileges are no longer needed,//it’s time to relinquish the root privileges permanently.
  setuid(getuid()); // getuid() returns the real uidif (fork())
  { // In the parent process
   close (fd);
    exit(0);
  }
  else
  { // in the child process//Now, assume that the child process is compromised, malicious//attackers have injected the following statements//into this process
   write (fd, "shiyanlou!", 10);
  close (fd);
  }
}

Results

The file was modified because the zzz file was opened before the UID was set. This problem can be avoided as long as the statement setuid (Getuid ()) is moved to the call to the open function.

Third. problems encountered in the experiment

1, in the step 2.5.1, to the/bin/sh point to Zsh, at first did not notice the operation

2. When creating a new file, use the vi file command

Fourth. Summary of the experiment

Through this experiment, I learned that Set-uid is an important security mechanism in UNIX systems, and if the owner of the program is root, then anyone running the program will get permission from the program owner. Set-uid allows us to do a lot of interesting things, but unfortunately, it is also the culprit of many bad things.

1, by step 2.2.2 can know,/bin/bash has some kind of intrinsic protection mechanism can prevent set-uid mechanism abuse. To be able to experience the situation before this intrinsic protection mechanism occurs, we intend to use another shell program--/bin/zsh.

2, from step 2.6 can be known that only the user created by themselves to run the program, will use the LD_PRELOAD environment variable, overloaded sleep function, otherwise ignore the LD_PRELOAD environment variable, do not overload the sleep function.

SET-UID Program Vulnerability Experiment