Project 4: Access Control

Date Assigned:

Date Due:

1 Explore the Set-UID Mechanism............................................................................1

1.1 Explore Set-UID programs................................................................................1
1.2 Run Set-UID shell programs.............................................................................2
1.3 The PATH environment variable.......................................................................2
1.4 The Difference Between system() and execve()..............................................3
2 Using File Capabilities Instead Of Set-UID.............................................................5
3 Command Injection Attack.................................................................................... 6
3.1 Download the packages...................................................................................6
3.2 Setup the web site........................................................................................... 7
3.3 Discover the injection script............................................................................. 7

Goal: Set-UID is an important security mechanism in UNIX like operating systems. When a Set-
UID program is run, it assumes the owners privileges. For example, if the programs owner is
root, then when anyone runs this program, the program gains the roots privileges during its
execution. Set-UID allows us to do many interesting things, but unfortunately, it is also the
culprit of many bad things. Therefore, the objective of this lab is two-fold: (1) Be able to
appreciate its good side: understand why Set-UID is needed and how it is implemented. (2) Be
aware of its bad side: understand its potential security problems.

1 Explore the Set-UID Mechanism

This is an exploration lab. Your main task is to play with the Set-UID mechanism in Linux,
and write a lab report to describe your discoveries.

1.1 Explore Set-UID programs

You are required to accomplish the following tasks in a Linux VM. Figure out why "passwd",
"chsh", "su", and "sudo" commands need to be Set-UID programs.
1.1.1 What will happen if they are not? 4 points)

If you are not familiar with these programs, you should first learn what they can do by reading
their manuals. Please copy these commands to your own directory; the copies will not be Set-
UID programs. Run the copied programs, and observe what happens. If you dont know where
these command files are located, type: whereis command_name.

1.2 Run Set-UID shell programs

Login as root, run the following command to install zsh: 2 points)
Page | 1
yum install zsh

Copy /bin/zsh to /tmp, and make it a set-root-uid program with permission 4755. 2 points)
chmod 4755 /tmp/zsh

Then login as a normal user, and run /tmp/zsh. 2 points)

1.2.1 Will you get root privilege? Please describe your observation. 4 points)

Instead of copying /bin/zsh, this time, copy /bin/bash to /tmp, make it a set-root-uid program
(using the chmod command as above). Run /tmp/bash as a normal user. 2 points)
1.2.2 Will you get root privilege? Please describe and explain your observation. 4
points)

As you can find out from the previous task, /bin/bash has certain built-in protection that prevent
the abuse of the Set-UID mechanism. To see the life before such a protection scheme was
implemented, we are going to use a different shell program called /bin/zsh. In some Linux
distributions (such as Fedora and Ubuntu), /bin/sh is actually a symbolic link to /bin/bash. To use
zsh, we need to link /bin/sh to /bin/zsh. The following instructions describe how to change the
default shell to zsh. As the root user, type the following commands: 2 points)
rm /bin/sh
ln -s /bin/zsh /bin/sh

1.3 The PATH environment variable

The system(const char *cmd) library function can be used to execute a command within a
program. The way system(cmd) works is to invoke the /bin/sh program, and then let the shell
program to execute cmd. Because of the shell program invoked, calling system() within a Set-
UID program is extremely dangerous. This is because the actual behavior of the shell program
can be affected by environment variables, such as PATH; these environment variables are under
users control. By changing these variables, malicious users can control the behavior of the Set-
UID program.

The Set-UID program below is supposed to execute the /bin/ls command; however, the
programmer only uses the relative path for the ls command, rather than the absolute path.

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

Use a text editor to write the program and save it (the file name can be set-uid.c) in /tmp
directory. Go the /tmp directory. Next, you can compile the program with gcc like this: 2
points)
gcc set-uid.c
An executable file named a.out will be created.
chmod 4755 a.out
this will give a.out the set-UID previlige. 2 points)
Page | 2
Copy an arbitrary file (for convenience, we use vi) to /tmp folder and name it as ls: 2 points)
cp /bin/vi /tmp/ls

Run the a.out as root by typing: 2 points)

./a.out
Observe the results for future reference.

Now, open another terminal and login as a regular user. In bash, you can change the PATH
environment variable in the following way (the following example adds the current directory to
the beginning of the PATH environment variable):
export PATH=.:$PATH 2 points)
Note that the current directory is a relative concept. It can be any directory that you are currently
at (i.e., the actual current directory changes as you change folder).

Go the /tmp directory, type (note that no ./ in front of a.out): 2 points)

a.out

1.3.1 Can you let this Set-UID program (a.out owned by root) run your program (the
vi) instead of /bin/ls? If you can, is your code running with the root privilege?
Describe and explain your observations. 4 points)

Note that, you can check the privileges with the command: 2 points)
ps -le

Now, change /bin/sh so it points back to /bin/bash, and repeat the above attack. 2 points)
rm /bin/sh
ln -s /bin/bash /bin/sh
1.3.2 Can you still get the root privilege? Describe and explain your observations.
4 points)

1.4 The Difference Between system() and execve()

Before you work on this task, please make sure that /bin/sh is pointed to /bin/zsh. To achieve
that, as the root user, type the following commands: 2 points)
rm /bin/sh
ln -s /bin/zsh /bin/sh

Background: Bob works for an auditing agency, and he needs to investigate a company for a
suspected fraud. For the investigation purpose, Bob needs to be able to read all the files in the
companys UNIX system; on the other hand, to protect the integrity of the system, Bob should
not be able to modify any file. To achieve this goal, Vince, the super user of the system, wrote a
special set-root-uid program (see below), and then gave the executable permission to Bob. This
program requires Bob to type a file name at the command line, and then it will run /bin/cat to
display the specified file. Since the program is running as a root, it can display any file Bob

Page | 3
specifies. However, since the program has no write operations, Vince is very sure that Bob
cannot use this special program to modify any file.

#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 related to system(), and q = 1 for related to execve() */

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 ;
}

Use a text editor to write the program and save it (the file name can be audit.c) in /tmp directory.
Set q = 0 in the program. This way, the program will use system() to invoke the command. 2
points)
Go the /tmp directory. Next, you can compile the program with gcc like this: 2 points)
gcc audit.c
An executable file named a.out will be created. 2 points)
chmod 4755 a.out
This will set the a.out as with the set-UID privilege.
1.4.1 Is this program safe? If you were Bob, can you compromise the integrity of
the system? 4 points)

For example, can you remove any file that is not writable to you? Create a file named root_file
as the root user under /tmp folder. Modify the root_file with a.out as a regular user. (Hint:
remember that system() actually invokes /bin/sh, and then runs the command within the shell
environment. We have tried the environment variable in the previous task; here let us try a
different attack. Please pay attention to the special characters (such as > and ) used in a normal
shell environment).
Page | 4
Next, set q = 1 in the program. This way, the program will use execve() to invoke the command.
Redo the compilation and privilege settings. 2 points)
1.4.2 Do your attacks in the previous task still work? Please describe and explain
your observations. 4 points)

Once you finish this task, please change /bin/sh so it points back to /bin/bash. 2 points)
rm /bin/sh
ln -s /bin/bash /bin/sh

2 Using File Capabilities Instead Of Set-UID

In a capability system, when a program is executed, its corresponding process is initialized with
a list of capabilities (tokens). When the process tries to access an object, the OS checks the
process capabilities and decides whether to grant the access or not.

In operating systems, there are many privileged operations that can only be conducted by
privileged users. Examples of privileged operations include configuring network interface card,
backing up all the user files, shutting down the computers, etc. Without certain capabilities, these
operations can only be carried out by super users, who often have many more privileges than
what are needed for the intended tasks. Therefore, letting super users to conduct these privileged
operations is a violation of the Least-Privilege Principle. Privileged operations are very
necessary in operating systems. All Set-UID programs involve privileged operations that cannot
be performed by normal users. To allow normal users to run these programs, Set-UID programs
turn normal users into powerful users (e.g. root) temporarily, even though that the involved
privileged operations do not need all the power. This is dangerous: if the program is
compromised, adversaries might get the root privilege.

Capabilities divide the powerful root privilege into a set of less powerful privileges. Each of
these privileges is called a capability. With capabilities, we do not need to be a super user to
conduct privileged operations. All we need is to have the capabilities that are needed for the
privileged operations. Therefore, even if a privileged program is compromised, adversaries can
only get limited power. This way, risk of privileged program can be lowered quite significantly.

Capabilities have been implemented in Linux for quite some time, but they could only be
assigned to processes. Since kernel version 2.6.24, capabilities can be assigned to files (i.e.,
programs) and turn those programs into privileged programs. When a privileged program is
executed, the running process will carry those capabilities that are assigned to the program. In
some sense, this is similar to the Set-UID files, but the major difference is the amount of
privileged carried by the running processes.

We will use an example to show how capabilities can be used to remove unnecessary power
assigned to certain privileged programs. First, let us login as a root user, and run the following
command. 2 points)
ll /bin/ping

Page | 5
If you look at the file attribute of the program /bin/ping, you will find out that ping is actually a
Set-UID program with the owner being root, i.e., when you execute ping, your effective user id
becomes root, and the running process is very powerful. If there are vulnerabilities in ping, the
entire system can be compromised. The question is whether we can remove these privileged from
ping.

Let us turn /bin/ping into a non-Set-UID program. This can be done via the following command
(you need to login as the root): 2 points)
chmod u-s /bin/ping

Now, run ll /bin/ping, and see what happens. 2 points)

Let us only assign the cap net raw capability to ping. As the root user, type the following
command: 2 points)
setcap cap_net_raw=ep /bin/ping

Next, you can run ll /bin/ping, and see what happens. 2 points)

3 Command Injection Attack

The main concept behind this section is server-side scripting vulnerability.

3.1 Download the packages

Log into one of your FC VMs. Open a terminal and become root. Download the package file (a
zip file) from Blackboard. Its name is extremeinsecure.zip.

Install the php package as the root: 2 points)

yum install php

3.2 Setup the web site

Move the zip file to /var/www/html directory. Simply unzip it, extracting it to a folder named
extremeinsecure. All the files and folders will be automatically created. 3 points)
cd /var/www/html
unzip extremeinsecure.zip

Now, you need to setup the correct permission on the files and folders. Set read permissions for
files (604) and execute permission for directories (705). Make sure that process.php also has
execute permissions or it will not run. You can do so by typing the following commands: 3
points)
chmod -R 604 extremeinsecure
chmod +x extremeinsecure
cd extremeinsecure
ll | grep ^d | awk '{print $9}' | xargs chmod 705
chmod +x process.php
3.2.1 Explain the meaning of these permissions (i.e., 604 and 705). 4 points)
Page | 6
Next, restart the httpd service: 2 points)
service httpd restart

3.3 Discover the injection script

Open a browser and type: http://ip_address_of_this_machine/extremeinsecure/index.htm. If
configured properly, the extreme in security company web site will show up. Browse the web
site. Make sure every link and file is properly functioning and that no obvious vulnerabilities
strike immediately. You need discover the page/script that has a server-side injection/scripting
vulnerability. (Hint, pay attention to the php files). 5 points)
3.3.1 Explain your discovery. 5 points)

Page | 7