SET-UID program vulnerability lab

20125102 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

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.

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.

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.

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.

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 Bob cannot use this program to modify any files.

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 this 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.

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.

Iii. problems encountered in the experiment

1. In Step 2.6.4, I encountered the problem of insufficient permission to change myprog.

2. The experiment requires that the ZZZ file contains data after the attack, but the attack fails when you operate it yourself.

Iv. Experiment experience

 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

In this experiment, steps 2.1 and 2.2 show that/bin/Bash has an internal protection mechanism to prevent the abuse of the Set-UID mechanism. Steps 2.3 to 2.5 can be found, the sh symbol in the/bin/directory is linked to zsh, and the Environment Variable path is set to the current directory/tmp. Run the compiled program test to obtain the root permission, if you modify sh to connect to bash, running the test program does not give normal users the root permission.

As you can see in step 2.6, ld_preload environment variables will be used and sleep functions will be reloaded only when the program you have created runs on your own. Otherwise, ld_preload environment variables will be ignored and sleep functions will not be reloaded. In the future, I will certainly learn more about Linux and strive to have a better grasp of it.

SET-UID program vulnerability lab