-----BEGIN PGP SIGNED MESSAGE-----


	Why you should never unpack files as root
       or the risk of insecure client applications
      =============================================

   Security papers - members.tripod.com/mixtersecurity/papers.html

_______________________________________________________________________________


A widely spread belief is that the only major security breach in which
a local user is tricked into putting his own system at risk is by
executing binaries or accessing other content that somehow executes
on the system (java, unix/windows script languages etc.) with trojan,
virus, or other malicious intent.

This is not true, as many, many normal applications are not designed
with security in mind and can be compromised with some work. Think of
software separated into server software, which usually waits readily
on a port or is run as a daemon in background that regularly monitors
configuration files, or gives users the ability to use its services
while performing privileged tasks that the users do not perform
themselves in any other way, and into client / normal software,
every program that a user directly runs to contact servers or perform
any other tasks that do not require more privileges than the average
user has. (You have probably already noticed that I am focusing on
multi user / UNIX systems - on "Desktop" operating systems like MacOS/
Windows (and WinNT regarding some issues) many of these client tasks
are performed with system privileges or there is no difference between
user and system rights which makes exploitation a very easy task.)

It is relatively easy and has become a popular sport to compromise a
buggy or insecure server (or SUID program, for this matter), because
it is always readily available to any user, running with high / system
privileges, and in a predictable state of execution. Therefore, server
software is starting to be written securely and audited with scrutiny.

However, not much, if any, security effort is usually being made when
composing client software, because it isn't available to the user with
high privileges, and therefore harder to use for compromising security,
although it can be (and has been) proven, that *any* insecure software
can be a viable tool to breach security at the permission level or
user account that a peculiar program is run.

Examples for rather big security problems that were a result of security
problems found in normal non-suid programs are those discovered in some
versions of MS-Internet Explorer, MS-Outlook, Netscape (Windows) or
elm, pine, lynx (UNIX).

Taking a general approach on exploitation of client programs, one has
to either find a condition that always happens predictably if a program
is run by anyone - access to remote server content, or a server (overflow
or other input parsing bugs), or files that you have access to, or
predictably generated temp files (race conditions) - or the user has to
be actively tricked into using the program in an insecure manner (when
there is no "real" security fault in the program, but it is hard to
understand, or has insufficient warning mechanisms to tell the user what
he is doing).

To conclude, if any program can be predicted to reach a special condition
where it accesses files or content that can be modified by non trusted
users or servers, chances are "good" that it can be used to compromise
the privileges of the user it is run by. The security issue is especially
serious if the program:

1) is run frequently by root or system users
2) is a widely spread and used tool that many people run as root
3) is silently executed by front-end programs
4) is often run periodically by scheduling daemons (like crontab or atd)

_______________________________________________________________________________

As an example, here is an example on how to use the tar program
to fool root into installing a virus on his system, just by unpacking
a file as root. You should generally NEVER unpack files as root, no
matter in which directory you are in. I did NOT discover it, this
particular hole is a known issue for a very long time, even mentioned
on bugtraq. Just an example that you should run as few programs as
possible as root as you can.

Lets have a look at the file dont_unpack.tgz... it is compiled to look
like a directory with a linuxconf exploit and a precompiled binary...

$ tar tzvf dont_unpack.tgz
- -rwxr-xr-x root/root    103808 1999-10-28 20:24 linexp/linexp
      ^ The binary (This is actually the WoodWorm UNIX virus I wrote,
                    watch out. Lets assume you wouldn't execute this.)
lrwxrwxrwx root/root         0 1999-10-28 20:13 linexp/   -> /bin/ls
      ^ The directory? No, a symlink to /bin/ls, with the name "linexp/  " !
- -rwxr-xr-x root/root       192 1999-10-28 20:24 linexp/
      ^ The same file "linexp/  " again, this time a malicious shell script
- -rw-r--r-- root/root      1562 1999-10-28 20:24 linexp/linexp.c
      ^ The actual source file

Now, when root unpacks the file, this is what happens:
1. linexp/ directory is created, linexp/linexp (the virus)
   is unpacked into it.
2. "linexp/  " symlink is created, pointing to /bin/ls
3. "linexp/  " (script) is unpacked, the symlink is already there,
   what happens here? tar doesn't recognize the symlink, and overwrites
   the file - it overwrites /bin/ls !!!

Now root looks into linexp/, and after some time does 'ls -la'.
The shell script copied over /bin/ls gets executed, it copies the "vdir"
binary (which behaves almost exactly like 'ls') over /bin/ls, and then...
silently runs the virus linexp/linexp!

The user, in this case root, has been successfully tricked into executing
arbitrary commands, the client application has been exploited.

_______________________________________________________________________________

Mixter <mixter@newyorkoffice.com>
http://members.tripod.com/mixtersecurity

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQEVAwUBOFerqrdkBvUb0vPhAQHMFAf/QaadDAm0AsId+/PlSjks5TvhLXSy+qe6
+o6qRYfBrvAKnycSBQd0pjcEkrVMDQtqaovs2xHOsj6AuoKwpJKzqdESAsAlxRlt
UPmAhMBffD0xTg0CItkSDsgWkR/EuJphcCar1wJIF8OoIJoEDAQjT6cbdCzsC88r
xCLmVZhEBk9zykyznGW2zOJmOCnu//+XxI0W0urddcuj1L95fyhZii5IF3L7hk78
cmKZ1f2D0zp1/hA/rqYz64BdhuSE58ekbHfAEbCSGA0SM14d+lNS36NfrhUyUeef
A2iwv1+Nf5Ens23ZudR1WtcCWPDdqdP58GCdzriVGdiXw7vXEPJ49g==
=54vp
-----END PGP SIGNATURE-----
