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.

Run/tmp/zsh has root access.

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.

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:

Run the test program and gain 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.

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:

The operation has encountered some problems after this step:

The "Ls-la file;ls-la SRU" statement was not found at first because it could not be executed because it could not find the file, and then it created a file that ran to the "./sru" FILE;MV file The file_new "" statement appears garbled, but "ls" is executedto see the file rename succeeded .

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:

The file_new file renaming shown is unsuccessful.

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):

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:

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:

You can see that the sleep function is overloaded.

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:

The sleep function is not overloaded.

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:

The sleep function is overloaded.

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:

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>

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

Sleep (1);

After the task, the root privileges is 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 this child process is compromised, malicious

Attackers has 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. Summary of the experiment

1, the passwd copy to the/tmp/, the permissions have changed (in the original directory suid bit is set), the copy does not have the right 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,/bin/bash has some kind of intrinsic protection mechanism can prevent the abuse of set-uid mechanism.

3,the/bin/directory of the SH symbol link to zsh, the environment variable path is set to the current directory/TMP, run the compiled program test, you can get root permissions, if you modify the SH connection back to bash, Running the test program does not allow the normal user to gain root privileges;

4, only the user to create their own program to run, will use LD_PRELOAD environment variables, overloaded sleep function, otherwise ignore LD_PRELOAD environment variables, do not overload sleep function;

5, the Statement setuid (Getuid ()) moved to the call to the open function, under a normal user, to prevent tmp/zzz this file will be modified.

SET-UID Program Vulnerability Experiment