tmp-advisory.txt

`  
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: [email protected]  
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,  
  
[email protected]  
---------------  
For more L0pht (that's L - zero - P - H - T) advisories check out:  
http://www.l0pht.com/advisories.html  
---------------  
`