From: "Dr. Mudge"
Subject: L0pht tmp tool and (mini) Advisory
To: BUGTRAQ@netspace.org
L0pht Security Tool and (mini)Advisory
Advisory released Jan 8 1999
Application: A tool designed to monitor directory
activity, copy transient files based upon regular
expression matching, syslog upon seeing links created,
etc. etc.
Severity: Just about every OS out there is replete
with programs that insecurely handle files in
publicly accesible temporary directories.
Author: mudge@l0pht.com
http://www.l0pht.com/advisories.html
Overview :
One of the most overlooked areas of exploit attention seems to be the use
of public holding or scratch areas. This tool allows :
. The white-hat: to monitor various directories and optionally log
upon seeing suspicious activity.
. The grey-hat: to run and collect the information to find system state
and information about user trends or new suspicious programs
. The black hat: to ease copying of sensitive, potentially transient, data
and to aid in locating exploitable programs and creating said exploits
Needless to say. It's good to feel comfortable wearing any colour hat.
The tool is available at http://www.L0pht.com/advisories/l0pht-watch.tar.gz
Description :
A common shortcoming of programs is how they treat data and files in temporary
or holding areas. Many people have been silently exploiting many of these
problems for some time now. In a quick-throw-together way I decided to
write a program to both help analyze activity in these scratch areas.
The program is not the best way to do it for an individual architecture (which
would most likely be to hook in front of the system call entry points for
the appropriate file manipulation calls so as not to miss anything that
happens). This was done intentionally to allow quick porting to various
platforms at the loss of a small amount of accuracy.
The problems are of various types and severities. For example, people
calling open(2) while using O_CREAT without O_EXCL, mktemp(3C) being
too predictable, access(2) calls on files and trusting that the information
is still the same later on in ones code, stat(2) as opposed to fstat(2) or
lstat(2) in some situations. Other problems include placing sensitive data
in public places with incorrect permissions.
These problems happen not only in code written by novice coders but many times
by experienced security conscious programmers as well.
Ask Marcus Ranum about the time Casper Dik and I found problems with his
secure code examples in a public talk [side note: Marcus is a good security
conscious programmer - it simply became a case of staring at his own work
and not seeing the bugs that pop out to a new set of eyes. Much akin to
proofreading ones own papers].
Ask the l0phtcrack development team that recently had a temporary file problem
pointed out to them on the windows platform software [side note: the problem
was in the GUI portion of the code, which I did not write. This is not to
say that I haven't had problems with my code in the past, just that this
was not one of mine, which is contrary to what a couple of outspoken people
seem to have thought. ;) We were actually happy that we had the opportunity
to react to the report in the way we always wanted other companies to react
to similar reports. We hope we did alright by everyone. In addition, I
have chopped off another finger of the person who wrote the code - call
it our 'internal incentive program'].
The tool opens the directory specified (defaults to /tmp) and continuously
reads the contents. Upon first read it spits out the list that it has
built (it attempts an ls -l style output). From that point on it shows
any additions or deletions that it sees prefaced with '+' or '-' accordingly.
Other options are for copying files that it witnesses and match regular
expressions, and daemonizing itself and subsequently syslog(3)ing anytime
a symbolic link is created in the directory being watched. I have watched
many, many temp files and have not seen legitimate uses of symbolic links
being created in them other than for exploit purposes.
I suppose the best way to see how / why / what the tool does is a quick
example of some curious behaviour that it witnessed in Solaris 2.5 and
the subsequent silent fix that seems to have been implemented in Solaris
2.6 [note: I looked through Sun's website for references of a patch but
could not find one - it is possible that it is there and I missed it.
However, it seems more likely that Sun fixed the problem for 2.6 and instead
of announcing the problem and issuing a patch for previous versions let
the 2.6 modified version go by as a 'silent fix'. This would imply a
willingess to let users of 2.5 remain vulnerable. There are, hopefully,
other reasons why this would have happened.]
The programs to be examined are crontab(1) and cron(1M).
On Solaris 2.5 we see the following behaviour for crontab when it is
invoked multiple times with -e:
+ -rw------- 1 mudge other 0 Jan 8 00:32 /tmp/crontaba0074F
- -rw------- 1 mudge other 0 Jan 8 00:32 /tmp/crontaba0074F
+ -rw------- 1 mudge other 58 Jan 8 00:32 /tmp/crontaba0074J
- -rw------- 1 mudge other 58 Jan 8 00:32 /tmp/crontaba0074J
+ -rw------- 1 mudge other 58 Jan 8 00:32 /tmp/crontaba0074N
- -rw------- 1 mudge other 58 Jan 8 00:32 /tmp/crontaba0074N
+ -rw------- 1 mudge other 58 Jan 8 00:32 /tmp/crontaba0074R
- -rw------- 1 mudge other 58 Jan 8 00:32 /tmp/crontaba0074R
As one can see, the random value that is created is far from random. In fact,
there are most likely 4 processes invoked throughout the life of crontab
and it's invocation of my EDITOR (vi). Hence the only dynamic value above,
which is the last character, is incremented by 4 each time.
On a Solaris 2.6 machine one notices the following behaviour:
+ -rw------- 1 mudge staff 0 Jan 8 08:17 /tmp/crontab0S0jWF
- -rw------- 1 mudge staff 0 Jan 8 08:17 /tmp/crontab0S0jWF
+ -rw------- 1 mudge staff 0 Jan 8 08:17 /tmp/crontabsp9ND_
- -rw------- 1 mudge staff 0 Jan 8 08:17 /tmp/crontabsp9ND_
+ -rw------- 1 mudge staff 0 Jan 8 08:17 /tmp/crontab0GdcDB
- -rw------- 1 mudge staff 0 Jan 8 08:17 /tmp/crontab0GdcDB
+ -rw------- 1 mudge staff 0 Jan 8 08:17 /tmp/crontabgQ349_
- -rw------- 1 mudge staff 0 Jan 8 08:17 /tmp/crontabgQ349_
The above 2.6 data looks much better than the 2.5 data.
Let us take a look at a situation where root has a recurring cron job that
runs every minute. We will see that cron(1M) will exhibit similar behaviour
as crontab(1) did above:
On the Solaris 2.5 machine:
+ -rw------- 1 root other 0 Jan 8 00:43 /tmp/croutTGEa0002o
- -rw------- 1 root other 0 Jan 8 00:43 /tmp/croutTGEa0002o
+ -rw------- 1 root other 0 Jan 8 00:44 /tmp/croutUGEa0002o
- -rw------- 1 root other 0 Jan 8 00:44 /tmp/croutUGEa0002o
+ -rw------- 1 root other 0 Jan 8 00:45 /tmp/croutWGEa0002o
- -rw------- 1 root other 0 Jan 8 00:45 /tmp/croutWGEa0002o
+ -rw------- 1 root other 0 Jan 8 00:46 /tmp/croutXGEa0002o
- -rw------- 1 root other 0 Jan 8 00:46 /tmp/croutXGEa0002o
+ -rw------- 1 root other 0 Jan 8 00:47 /tmp/croutYGEa0002o
- -rw------- 1 root other 0 Jan 8 00:47 /tmp/croutYGEa0002o
[it should be noted that with systems without a lot of cron activity (the
cron activity can easilly be determined by running temp-watch for a day or
so and looking at the crout activity) display the same problems between
larger time intervals]
As the reader can see, the only value being incremented in the above example
is the 11th digit. Completely predictable.
Let us again take a look at a Solaris 2.6 machine:
+ -rw------- 1 root other 0 Jan 8 08:43 /tmp/croutZBA0M9pVP
- -rw------- 1 root other 0 Jan 8 08:43 /tmp/croutZBA0M9pVP
+ -rw------- 1 root other 0 Jan 8 08:43 /tmp/croutACAnHfw3_
- -rw------- 1 root other 0 Jan 8 08:43 /tmp/croutACAnHfw3_
+ -rw------- 1 root other 0 Jan 8 08:43 /tmp/croutBCA0Fy3q8
- -rw------- 1 root other 0 Jan 8 08:43 /tmp/croutBCA0Fy3q8
+ -rw------- 1 root other 0 Jan 8 08:44 /tmp/croutCCAl2fDT_
- -rw------- 1 root other 0 Jan 8 08:44 /tmp/croutCCAl2fDT_
+ -rw------- 1 root other 0 Jan 8 08:44 /tmp/croutDCA0FPrOc
- -rw------- 1 root other 0 Jan 8 08:44 /tmp/croutDCA0FPrOc
Again - this looks much better in comparison.
Why does any of this matter? What happens when the filename about to be
created is a symbolic link? In the above cases the link is followed and
the file created. What happens if the persons umask is less strict? The
programs above inherit it. If you cannot see where this is going then
you might think about slowly getting up from the desk and asking for
a job transfer if you are a Unix security person or systems administrator
with a security component.
Try running the tool for a day and look through the output. You will most
likely be surprised by the droppings that are created and how many different
programs do not even make a paultry attempt to check for file existence or
create a random program name [ ie strings /usr/sbin/rpcbind | grep tmp to
see what fun one can have when rpcbind catches a signal and dies creating
those files as root and following links, there are many easy rootin'
erobs people will find too ].
Anyway - the tool, and it's source are free. As people might be able to tell,
it's getting late here so this message is becoming even more thin near the
bottom as I try to wrap up and experience this thing called sleep that I
catch people talking about.
I hope people find it useful.
cheers,
mudge@l0pht.com
---------------
For more L0pht (that's L - zero - P - H - T) advisories check out:
http://www.l0pht.com/advisories.html
---------------
