[NCLUG] Why not Root?

[John L. Bass]

Being a "little compromised" with user permissions on a personal UNIX/Linux
network machine is functionally equivalent to being "rooted". Files stored under
your UID/GID are NOT protected, much is readable on most systems, less writable,
and the attacker can freely use your machine until the trojans are cleared.

Something like being "just a little pregnant", you are, or you are not.

This is compounded by the fact that there is a larger body of code and system
resources to exploit to effect a "root" compromise, and install a root kit.
There is a huge body of code that has never been seriously security reviewed,
that a novice user might invoke while SUSER.

Direct attacks to attain the root password or install a root kit are relatively
easy if you can compromise a user that frequently does administrative tasks with
sudo or common "helper" scripts which ask for a clear text password.

Consider a user-kit which sets up a trojan and shell aliases for su, sudo,
ssh, ... etc, to harvest passwords next time you need to do an adminstrative
function.

Consider a user-kit that installs trojans for common commands in your bin
directory, which are likely to be executed when you su or sudo, and can be
intercepted by making sure your bin directory is at the head of your search
path by editing your .profile or shell startup scripts.

The more scripts and programs which are executed UID 0, the more places there
are to hide a trojan. Effectively making "Check Root Kit" programs and scripts
useless, as they are unlikely to notice subtle user trojans or a shell alias for
"ls", or "mv", or "rm", or "ifconfig", or "cups", that are likely to be executed
by an adminstrative need as root with the altered search path.

Ditto for perverting the loadable library path, substituting trogan .so files
that are used by nearly every executable.

The more user accessable scripts/programs that are run as UID 0 (root), the more
places there are for a compromised user account to gain root access, if that is
really needed by the attacker. Simple user mode access may well be more than
enough, when cron, at, and other systems can run jobs as that user during off
use time when they are less likely to be noticed by a clueful user.

How many people that use SU/SUDO/SSH/..etc frequently audit their .profile, bin
directory, shell rc files, "at" jobs, "cron" jobs, etc for trojans? Few.

So ... a user-kit compromise, might as well be a much better hidden "root-kit"
compromise that is highly unlikely to be noticed by automated root-kit scripts.

John

PS ... even for "well trusted" UID 0 applications, which are dynamically linked,
consider interesting attacks like trojan .so files using a chroot 'jail' to compromise
otherwise trusted applications. Even if the application clears it's environment
variables, the chroot 'jail' allows the attacker to control the file environment.

Consider running "yum update" or trapping the auto update after the attacker
diverts the mirror pool to a compromised pool using host routes or an altered
default route.

The pandora's box that is created by a user mode compromise is huge.