Experiment on--SET-UID program vulnerability in Linux test

SET-UID Program Vulnerability Experiment

20125121

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.

Ii. contents of the experiment

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.

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>

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;

}

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

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:

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>

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.

Experiment on--SET-UID program vulnerability in Linux test