SET-UID program vulnerability lab

SET-UID program Vulnerability Experiment 1. Experiment description

Set-UID is an important security mechanism in UNIX systems. When a set-UID program runs, it is assumed that it has the permissions of the owner. For example, if the program owner is root, anyone who runs the program will be given the permissions of the program owner. Set-UID allows us to do many interesting things, but unfortunately it is also the culprit of many bad things.

Therefore, the objectives of this experiment are as follows:

1. In terms of appreciation, understand why set-UID is needed and how it is executed.

2. Pay attention to the bad aspect and understand its potential security problems.

Ii. experiment content

This is an Exploratory experiment. Your task is to play games with the set-UID mechanism in Linux. You need to complete the following experiment tasks in Linux:

2.1 guess why "passwd", "CHSH", "Su", and "sudo" commands require the set-UID mechanism. If they do not have these mechanisms, what will happen, if you are not familiar with these programs, you can call and read the user manual to familiarize yourself with them. If you copy these commands to your own directory, these programs will not be set-UID programs, run these copied programs and observe what will happen.

From the above, we can see that the permission for copying passwd to/tmp/has changed (the SUID bit is set in the original directory), and the password modification permission is not available for the copy.

For "CHSH", "Su", and "sudo" commands, copying these programs to the user directory does not have the root permission.

2.2 run the set-UID program in Linux and describe and explain your observed Results 2.2.1 Log On As root, copy/bin/zsh to/tmp, at the same time, set zsh copied to the tmp directory to set-UID root permission, and then Log On As a normal user to run/tmp/zsh. Will you get the root permission? Describe your results.

, Obtained the permission

2.2.2 copy/bin/Bash to the/tmp directory, set bash under the/tmp directory as the set-UID root permission, and then log on as a common user to run/tmp/bash. Will you get the root permission? Describe your results.

It can be seen that in the same operation, zsh running replication can obtain the root permission, whereas bash cannot.

2.3 From the above steps, we can see that/bin/Bash has an internal protection mechanism that can prevent the abuse of the Set-UID mechanism. To be able to experience this kind of internal protection mechanism, we plan to use another shell program --/bin/zsh. In some Linux releases (such as redora and UBUNTU),/bin/sh is actually a symbolic link of/bin/bash. To use zsh, we need to link/bin/sh to/bin/zsh.

The following command points the default shell to zsh:

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

2.4 set the path environment variable

System (const char * cmd) System Call functions are embedded into a program to execute a command. System () calls/bin/sh to execute shell programs, then the shell program executes the CMD command. However, in a set-UID program, the system () function calls shell, which is very dangerous because the behavior of the shell program can be affected by environment variables, such as path; these environment variables can be controlled by users. By controlling these variables, malicious users can control the behavior of the Set-UID program.

The following set-UID program is used to execute the/bin/LS command. Then the programmer can use the relative path instead of the absolute path for the LS command.

int main(){   system("ls");   return 0;}

2.4.1 can you set this set-UID to run your own code instead of/bin/ls? If you can, do you have the root permission for your code? Describe and explain your observations.

You can have the root permission to copy/bin/sh to the/tmp directory and rename it as LS (ensure that the sh symbol in the/bin/directory is linked to zsh instead of BASH ), set the environment variable path to the current directory/tmp and run the compiled program test. You can get the root permission:

2.4.2 Modify/bin/sh to make it return to/bin/bash. Repeat the above attack, do you still get the root permission? Describe and explain your observations.

It can be seen that the sh connection is changed back to bash. running the test program does not allow normal users to get the root permission.

2.5 different sytem () and execve ()

First make sure that/bin/sh points to zsh

Background: Bob works for an audit agency and is investigating whether a company has fraud. For this purpose, he needs to read all the files in the company's UNIX system; on the other hand, he cannot modify any file to ensure system reliability. To achieve this, Vince-the super user of the system writes a SET-ROOT-UID program for him and gives Bob the permission to execute it. This program requires Bob to name a file in the command line, and then run the/bin/CAT command to display the file. Since this program runs with the root permission, it can display any file Bob wants to view. However, since this program has no write operations, Vince is confident that Bob cannot use this program to modify any files.

#include <string.h>#include <stdio.h>#include <stdlib.h>int main(int argc, char *argv[]){   char *v[3];   if(argc < 2)   {   printf("Please type a file name.\n");   return 1;   }   v[0] = "/bin/cat"; v[1] = argv[1]; v[2] = 0;  //Set q = 0 for Question a, and q = 1 for Question b   int 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);  }  else execve(v[0], v, 0);  return 0 ;}

In the 2.5.1 program, q = 0. The program uses system () to call the command line. This command security code? If you are Bob, can you compromise the integrity of the system? Can you move a file that has no write permission on you?

This command is not secure. Bob may drive reading or modifying files that only root users can run out of curiosity or personal interests. For example, only the root user has the read and write permissions for the file, but the common user reads and renames the file by running the program:

2.5.2 if q = 1 is enabled, will the attack still be effective? Describe and explain your observations.

It is invalid if it is changed to Q = 1. The preceding step is valid because the system () function calls/bin/sh and links to zsh. After the cat file is executed with the root permission, the MV file file_new command is executed.

When q = 1, execve () considers file; MV file file_new as a file name, and the system will prompt that the file does not exist:

2.6 ld_preload Environment Variables

To ensure the security of the Set-UID program in the ld_preload environment, the dynamic linker ignores the environment variables, but is exceptional under some conditions. In the following tasks, we guess what these special conditions are.

1. Let's create a dynamic link library. Name the following program mylib. C and put it in the/tmp directory. The sleep function is reloaded in the function library libc:

#include <stdio.h>void sleep (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.cgcc -shared -Wl,-soname,libmylib.so.1 -o libmylib.so.1.0.1 mylib.o –lc

3. Name the following program myprog. C and put it in the/tmp directory:

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

Run these programs under the following conditions and observe the results. Based on these observations, the linker will ignore the ld_preload environment variable and explain the cause.

2.6.1 compile myprog into a program under a common user and run it under a common user.

It can be seen that it uses the ld_preload environment variable and the sleep function is overloaded:

2.6.2 compile myprog into a set-UID root program to run under normal users

In this case, ignore the ld_preload environment variable, Do not overload the sleep function, and use the built-in sleep function:

2.6.3 compile myprog into a set-UID root program and run it under root.

In this case, use the ld_preload environment variable and the overloaded sleep function:

2.6.4 compile myprog into a set-UID common user program to run under another common user

In this case, the sleep function is not reloaded:

The preceding four cases show that ld_preload environment variables are used and sleep functions are reloaded only when the program you have created runs on your own. Otherwise, ld_preload environment variables are ignored and sleep functions are not reloaded.

2.7 remove and clear privileges

For higher security, the set-UID program usually calls the setuid () System Call function to permanently clear their root permissions. However, sometimes this is far from enough. Create an empty file zzz in the/tmp directory under the root user. Name the following code as test. C under the root user, put it in the/tmp directory, compile the program, and set the root permission for the program. Run this program under a common user. Describe what you have observed. Will the/tmp/ZZZ file be modified? Explain your observations.

Code:

#include <stdio.h>#include <stdlib.h>#include <sys/types.h>#include <sys/stat.h>#include <fcntl.h>void main(){  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 uid  if (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);  }}

Result

The file has been modified because the ZZZ file has been opened before the UID is set. You only need to move the setuid (getuid () statement to call the OPEN function to avoid this problem.

Iii. Experiment experience

This test is a SET-UID program Vulnerability Experiment, in general, the experiment is relatively simple, but because of the previous Completion of too early, resulting in later to see Miss Lou asked to complete the experiment in his student ID directory, I had to do it again. During the experiment, you need to pay attention to the Directory change. For this reason, the path to the student ID directory is: Home/shiyanlou/code/20125111, in the experiment, replace/tmp with/home/shiyanlou/code/20125111.

During the experiment, you should also note that there are a lot of small experiments that affect each other. It is best to restart the shell every time you finish one experiment.

In "2.6.4 compiling myprog into a set-UID program for a common user and running it under another common user", the system encountered insufficient permissions, it is proved that syl user permissions need to be improved.

Compared with the previous experiment, the content and knowledge points of this experiment are more complex, but more knowledge is learned.

SET-UID program vulnerability lab