SUID and SGID attributes

• Introduction

• Blocking SUID and SGID attributes in Mounted Filesystems

• SGID and Sticky Bits on Directories

• SGID Bit on Files: Mandatory Record Locking

• Creating a list of files with SUID SGID attributes using find

• SUID Shell Scripts

• suidperl defeats mounting nosuid attribute

• write: Example of a possible SUID/SGID security hole

• Another SUID example: IFS and the /usr/lib/preserve hole

NOTE: This lecture note is adapted from Practical UNIX and Internet Security, Second Edition - O'Reilly Media

Introduction

Sometimes, unprivileged (ordinary) Unix users must be able to accomplish tasks that require privileges. An example is the passwd program, which allows you to change your password. Changing a user's password requires modifying the password field in the /etc/shadow file. However, you should not give a user access to change this file directly - the user could change everybody else's password as well! Likewise, the mail program requires that you be able to write a message into the mailbox of another user, yet you should not to give one user unrestricted access to another's mailbox.

The problem with Unix is not that root is too powerful, but that ordinary users are too powerless.

To get around this problem, UNIX created the concept of assumed identity which is implemented using SUID attribute. Processes executing these programs can assume another UID or GID when they're running. A program that changes its UID is called a SUID program (set-UID); a program that changes its GID is called a SGID program (set-GID). SUID and SGID are independent attributes: a program can have both SUID and SGID set.

When a SUID program is run, its effective UID becomes that of the owner of the file, rather than of the user who is running it. This concept is was patented by AT&T; the patent has since been released into the public domain, as should all software patents, if software patents should be allowed at all.

If a program is SUID or SGID, the output of the ls -l command will have the x in the display changed to an s. If the program is sticky, the last x changes to a t as shown:

Blocking SUID and SGID attributes in Mounted Filesystems

If you mount remote network filesystems on your computer, or if you allow users to mount their own floppy disks or CD-ROMS, you usually do not want programs that are SUID on these filesystems to be SUID on your computer as well. In a network environment, honoring SUID files means that if an attacker manages to take over the remote computer that houses the filesystem, he can also take over your computer, simply by creating a SUID program on the remote filesystem and running the program on your machine. Likewise, if you allow users to mount floppy disks containing SUID files on your computer, they can simply create a floppy disk with a SUID ksh on another computer, mount the floppy disk on your computer, and run the program - making themselves root.

You can turn off the SUID and SGID bits on mounted filesystems by specifying the nosuid option with the mount command. You should always specify this option when you mount a foreign filesystem unless there is an overriding reason to import SUID or SGID files from the filesystem you are mounting. Likewise, if you write a program to mount floppy disks for a user, that program should specify the nosuid option (because the user can easily take his or her floppy disk to another computer and create a SUID file).

For example, to mount the filesystem /dev/vg00/lv03 in the /home directory  with the nosuid option, type the command:

/etc/mount -o nosuid /dev/vg00/lv03/home

Linux also support a -nodev option that causes the system to ignore device files that may be present on the mounted partition. You should use to increase security too.

An example of a SUID program is the su command:

ls -l /bin/su
-rwsr-xr-x 1 root    user    16384 Sep 3 1989 /bin/su

Any program can be SUID, SGID, or both SUID and SGID. Because this feature is so general, SUID/SGID has tremendous security implications.

For example, any user can become the superuser simply by running a SUID copy of bash or ksh that is owned by root. Fortunately, you must be root already to create a SUID version of shell that is owned by root. Thus, an important objective in running a secure UNIX computer is to ensure that somebody who has superuser privileges will not leave a SUID copy of shell on the system, directly or indirectly.

If you leave your terminal unattended, an unscrupulous passerby can destroy the security of your account simply by typing the commands:

cp /bin/sh /tmp/backdoor 
chmod 4755 /tmp/backdoor

These commands create a SUID version of the sh program. Whenever the attacker runs this program, the attacker becomes you - with full access to all of your files and privileges. The attacker might even copy this SUID program into a hidden directory so that it would only be found if the superuser scanned the entire disk for SUID programs. Not all system administrators do such scanning on any regular basis, but generally this is one thing that should be always scheduled from cron with diff of the set of known suid program performed on the result and if discrepancies are found mail to sysadmin.

Note that the program copied does not need to be a shell. For instance, consider a SUID version of  vi. With it, not only can he read or change any of your files, but he can also spawn a shell running under your UID.

Most SUID system programs are SUID root; that is, they become the superuser when they're executing. In theory, this aspect is not a security hole, because a compiled program can perform only the function or functions that were compiled into it. (That is, you can change your password with the passwd program, but you cannot alter the program to change somebody else's password.) But many security holes have been discovered by people who figured out ways of making a SUID program do something that it was not designed to do. In many circumstances, programs that are SUID root could easily have been designed to be SUID something else (such as daemon, or some UID created especially for the purpose).

Too often, SUID root is used when an account with less privilege would be sufficient.

SGID and Sticky Bits on Directories

Although the SGID and sticky bits were originally intended for use only with programs, Linux, Solaris and other Unix flavours also use these bits to change the behavior of directories:

• SGID bit. The SGID bit on a directory controls the way that groups are assigned for files created in the directory. If the SGID bit is set, files created in the directory have the same group as the directory if the process creating the file also is in that group. Otherwise, if the SGID bit is not set, or if the process is not in the same group, files created inside the directory have the same group as the user's effective group ID (usually the primary group ID).
   
• Sticky bit. If the sticky bit is set on a directory, files inside the directory may be renamed or removed only by the owner of the file, the owner of the directory, or the superuser (even if the modes of the directory would otherwise allow such an operation); on some systems, any user who can write to a file can also delete it. This feature was added to keep an ordinary user from deleting another's files in the /tmp directory.

  For example, typically sticky bit is set on  /tmp directory (and the attributes are 1777) so that any user can create or delete her own files but can't delete another's use files

To set sticky bit on a home directory, type the command:

chmod 1751 /home/myself

SGID Bit on Files: Mandatory Record Locking

If the SGID bit is set on a non-executable file, AT&T System V UNIX implements mandatory record locking for the file. Normal UNIX record locking is discretionary; processes can modify a locked file simply by ignoring the record-lock status. On System V UNIX, the kernel blocks a process which tries to access a file (or the portion of the file) that is protected with mandatory record locking until the process that has locked the file unlocks it. Mandatory locking is enabled only if none of the execute permission bits are turned on.

Mandatory record locking shows up in an ls listing in the SGID position as a capital "S" instead of a small "s".

Creating a list of files with SUID SGID attributes using find

Files with the SUID or SGID bit set execute with privileges of the owning user or group and not the user executing the file. Normally these bits are used on files that must run as root in order to do what they do. These files can lead to local root compromises (if they contain security holes). 

The first step in controlling SUID root programs is to have a baseline, the list of all SUID program in the system. This can be achieved quite easily by using find:

find / -type f \( -perm -4000 -o -perm -2000 \) -exec ls -lg {} \; 2>/dev/null >suidfiles.txt

Or it you are interested only in files owned by root:

find / -type f  -user root \( -perm -4000 -o -perm -2000 \) -exec ls -lg {} \; 2>/dev/null >suidfiles.txt

Notes:

1. This will find both set user id and set group id programs.
2. Please note that this program does not detect all SUID programs available on the system, there might be directories perversely set to permissions 000
3. Attempts of rogue users to install SUID programs in their home directories are best blocked by using nosuid mounting option for /home partition.
4. Solaris used to have a script called fix-modes written by Casper Dik that changed permission in a more reasonable, secure set. Such script can be created for any OS. For example on most modem systems it does not make sense to preserve SUID attribute uucp and similar "never used" programs.
5. Most modern Unixes block usage of SUID attribute on shell scripts.

Above command is using GNU find and executes ls command. You can use option -ls instead but output will be slightly different. Solaris POSIX find command is different:

find / -type f \( -perm -4000 -o -perm -2000 \) -exec ls -l {} \; 

This command will find all the SUID programs on a system and pipes the commands to a file called suid.list. The next step in controlling SUID root programs is to analyze which programs should not be SUID root or can be removed without impeding system functionality. An obvious example of something that should not be SUID root is /usr/X11R6/bin/SuperProbe.  This is a program merely used for testing purposes.

'chmod -s /usr/X11R6/bin/SuperProbe'

Other programs that are unneeded to be SUID root include anything in the svgalib  hierarchy. This library itself is buggy and nothing that depends on it should be SUID root in a secure system.

Here is an example of minimized suid.lst though perhaps a little too overzealous. For example, the functionality that does not exist with this setup is ability to use ping and traceroute by a regular users and this is close to a security paranoia. It can be compensated by controlling access to those program via sudo.

But in any case minimization of the number of SUID program is task worth trying. It is excessive zeal that hurts...

See also Finding SUID/SGUID files

SUID Shell Scripts

In some versions of UNIX, you can create shell scripts that are SUID or SGID. That is, you can create a shell script and, by setting the shell script's owner to be root and setting its SUID bit, you can force the shell script to execute with superuser privileges.

You should never write SUID shell scripts.

Because of a fundamental flaw with the UNIX implementation of shell scripts and SUID, you cannot execute SUID shell scripts in a completely secure manner on systems that do not support the /dev/fd device. This flaw arises because executing a shell script under UNIX involves a two-step process: when the kernel determines that a shell script is about to be run, it first starts up a SUID copy of the shell interpreter, then the shell interpreter begins executing the shell script. Because these two operations are performed in two discrete steps, you can interrupt the kernel after the first step and switch the file that the shell interpreter is about to execute. In this fashion, an attacker could get the computer to execute any shell script of his or her choosing, which essentially gives the attacker superuser privileges.

Most modern UNIX systems ignore the SUID and SGID bits on shell scripts for this reason.   Instead of writing SUID shell scripts, we suggest that you use the Perl programming language for these kinds of tasks. Perl -T option will force you to write SUID scripts that check their PATH environment variable and that do not use values supplied by users for parameters such as filenames unless they have been explicitly "untainted." Perl has many other advantages for system administration work as well.

suidperl defeats mounting nosuid attribute

Alternately, it can ask Unix simply to ignore the set-id bits on scripts if you mount filesystem as nosuid. If the latter is true, Perl can emulate the setuid and setgid mechanism when it notices the otherwise useless setuid/gid bits on Perl scripts. It does this via a special executable called suidperl that is automatically invoked for you if it's needed.

So while nosuid option for filesystems looks safe,  if  suidperl(1)  is installed on your system it is in fact rather unsafe.

write: Example of a possible SUID/SGID security hole

The authors of SUID and SGID programs try to ensure that their software won't create security holes. Sometimes, however, a SUID or SGID program can create a security hole if the program isn't installed in the way the program author planned.

For example, the write program, which prints a message on another user's terminal, is SGID tty. For security reasons, UNIX doesn't normally let users read or write information to another's terminal; if it did, you could write a program to read another user's keystrokes, capturing any password that she might type. To let the write program function, every user's terminal is also set to be writable by the tty group. Because write is SGID tty, the write program lets one user write onto another user's terminal. It first prints a message that tells the recipient the name of the user who is writing onto her terminal.

But write has a potential security hole - its shell escape. By beginning a line with an exclamation mark, the person using the write program can cause arbitrary programs to be run by the shell. (The shell escape is left over from the days before UNIX had job control. The shell escape made it possible to run another command while you were engaged in a conversation with a person on the computer using write.) Thus, write must give up its special privileges before it invokes a shell; otherwise, the shell (and any program the user might run) would inherit those privileges as well.

The part of the write program that specifically takes away the tty group permission before the program starts up the shell looks like this:

setgid(getgid()); /* Give up effective group privs */ 
execl(getenv("SHELL"),"sh","-c",arg,0);

Notice that write changes only its GID, not its effective UID. If write is installed SUID root instead of SGID tty, the program will appear to run properly but any program that the user runs with the shell escape will actually be run as the superuser! An attacker who has broken the security on your system once might change the file permissions of the write program, leaving a hole that he or she could exploit in the future. The program, of course, will still function as before.

Another SUID example: IFS and the /usr/lib/preserve hole

Sometimes, an interaction between a SUID program and a system program or library creates a security hole that's unknown to the author of the program. For this reason, it can be extremely difficult to know if a SUID program contains a security hole or not.

One of the most famous examples of a security hole of this type existed for years in the program called /usr/lib/preserve (which is now given names similar to /usr/lib/ex3.5preserve). This program, which is used by the vi and ex editors, automatically makes a backup of the file being edited if the user is unexpectedly disconnected from the system before writing out changes to the file. The preserve program writes the changes to a temporary file in a special directory, then uses the /bin/mail program to send the user a notification that the file has been saved.

Because people might be editing a file that was private or confidential, the directory used by the older version of the preserve program was not accessible by most users on the system. Therefore, to let the preserve program write into this directory, and let the recover program read from it, these programs were made SUID root.

Three details of the /usr/lib/preserve implementation worked together to allow knowledgeable system crackers to use the program to gain root privileges:

1. preserve was installed SUID root.
2. preserve ran /bin/mail as the root user to alert users that their files had been preserved.
3. preserve executed the mail program with the system() function call.

The problem was that the system function uses sh to parse the string that it executes. There is a little-known shell variable called IFS, the internal field separator, which sh uses to figure out where the breaks are between words on each line that it parses. Normally, IFS is set to the white space characters: space, tab, and newline. But by setting IFS to the slash character (/) then running vi, and then issuing the preserve command, it was possible to get /usr/lib/preserve to execute a program in the current directory called bin. This program was executed as root. (/bin/mail got parsed as bin with the argument mail.)

If a user can convince the operating system to run a command as root, that user can become root. To see why this is so, imagine a simple shell script which might be called bin, and run through the hole described earlier:

There is actually a small bug in this shell script; can you find it?

# 
# Shell script to make an SUID-root shell 
# 
cd /homes/mydir/bin 
cp /bin/sh ./sh 
# Now do the damage! 
chown root sh 
chmod 4755 sh 

This shell script would get a copy of the Bourne shell program into the user's bin directory, and then make it SUID root. Indeed, this is the very way that the problem with /usr/lib/preserve was exploited by system crackers.

The preserve program had more privilege than it needed - it violated a basic security principle called least privilege. Least privilege states that a program should have only the privileges it needs to perform the particular function it's supposed to perform, and no others. In this case, instead of being SUID root, /usr/lib/preserve should have been SGID preserve, where preserve would have been a specially created group for this purpose. Although this restriction would not have completely eliminated the security hole, it would have made its presence considerably less dangerous. Breaking into the preserve group would have only let the attacker view files that had been preserved.

Although the preserve security hole was a part of UNIX since the addition of preserve to the vi editor, it wasn't widely known until 1986. For a variety of reasons, it wasn't fixed until a year after it was widely publicized.

NOTE: If you are using an older version of UNIX that can't be upgraded, remove the SUID permission from /usr/lib/preserve to patch this security hole.

Newer editions of UNIX sh ignore IFS if the shell is running as root or if the effective user ID differs from the real user ID. Many other shells have similarly been enhanced, but not all have. The idea that there are still programs being shipped by vendors with this same IFS vulnerability inside is interesting and very depressing. The general problem has been known for over 10 years, and people are still making the same (dumb) mistakes.

Top Visited					Switchboard
					Latest
					Past week
					Past month

NEWS CONTENTS

• 190813 : Securing a fresh Linux install, part 2 ( Linux.com )

Old News

Securing a fresh Linux install, part 2

Linux.com

SUID and SGID files

SUID and SGID files are executables which, when run by a normal user, may have access to resources not normally available to the user running the program. For example, an SUID program could have the permissions:

-r-sr-xr-x 1 root root 11267 Jan 21 00:28 /usr/sbin/foo

The s in the owner's permission field in place of the usual x indicates that /usr/sbin/foo is SUID. If run by a normal user, the executable will run with the privileges of the owner of the file, in this case root. In this case the program will have access to the same system resources as root.

Below is an example of an SGID file:

-r-xr-sr-x 1 root foo 11267 Jan 21 00:28 /usr/sbin/foo

Here there is an s in the place of the group's executable bit, meaning the file is SGID and will be executed with the group permissions of the foo group.

SGID and SUID programs may be used by a cracker to gain elevated permissions on a system, so you should keep track of such files. You can find SUID and SGID files using find:

# find / -perm -4000 -o -perm -2000 -exec ls -ldb {} \; >> SUID_files.txt

This command finds all SUID or SGID files and lists them in a file called SUID_files.txt. You can unset SUID or SGID privileges with the command chmod -s /usr/sbin/foo, but be warned, unsetting the SUID or SGID bit on some programs may mean that they will no longer run. Periodically check for new files.

There should be no reason for users to have SUID files in their home directories so you should use the nosuid option in /etc/fstab for the partition containing users $HOME directories. For example:

/dev/hda3 /home ext3 defaults,nosuid 1 1

World readable/writable files

Files should be world readable or writable only for very good reasons. You should check for such files the way we did above for SGID and SUID files:

# find / \( -perm -a+r -o -perm -a+w \) ! -type l >> world_readwrite.txt

Again, check through the list and remove permissions from files that do not need to be world readable or writable, and run checks regularly for new world readable or writable files.

Files with no owner or group

Ownerless files can be an indication that someone has gained access to your system. You should check regularly using the command

# find / -nouser -o -nogroup

. If you find any ownerless files, either delete them, or, if you know what they are and wish to keep them, assign them to an appropriate user and group. For example, assign myfile to the user foo and the group bar you would issue the command

# chown foo.bar myfile

Recommended Links

• setuid - Wikipedia, the free encyclopedia
• Sticky bit - Wikipedia, the free encyclopedia
• [Chapter 5] 5.5 SUID
• Care and Feeding of SUID and SGID Scripts (Unix Power Tools, 3rd ...
• UNIX Basics - File Access Permissions
• Practical UNIX and Internet security - Google Books Result
• Unix File and Directory Permissions and Modes
• Files and File system Security

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019