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.
Ii. 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.
It's supposed to be my new password. 123456 is too simple.
So I made another attempt to use a complex password
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/bin/zsh to/tmp, and set the zsh of the copy to the TMP directory to Set-uid root, then log in as a normal user , run/tmp/zsh. Will you get root privileges? Please describe your results.
Practice:
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.
Practice:
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 suPassword:#cd /bin#rm sh#ln -s zsh sh
Practice:
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.
int main(){ system("ls"); return 0;}
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 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;}
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:
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>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):
-fPIC -g -c mylib.cgcc -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:
int main(){ sleep(1); return 0;}
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 is no longer needed, //it ' s time to relinquish the root privileges Permane ntly. 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 ' child ' process is compromised, malicious //attacker S has injected the following statements //into this process write (FD, "shiyanlou!", Ten); 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.
SET-UID Program Vulnerability Experiment