[2158] in bugtraq
Re: -rw-rw-rw- 1 root 8025 Aug 24 04:10 /tmp/.lsof_dev_cache
daemon@ATHENA.MIT.EDU (Vic Abell)
Mon Aug 28 23:20:28 1995
Date: Mon, 28 Aug 1995 11:13:44 -0500
Reply-To: abe@cc.purdue.edu
From: Vic Abell <abe@vic.cc.purdue.edu>
X-To: Bugtraq List <BUGTRAQ@CRIMELAB.COM>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@CRIMELAB.COM>
In-Reply-To: Your message of Fri, 25 Aug 95 12:49:52 -0400.
<Pine.SUN.3.91.950825123658.25410A-100000@di>
In message <Pine.SUN.3.91.950825123658.25410A-100000@di> Scott Barman writes:
>
>Finally, according to the 00FAQ file in the source directory (and I
>picked up my copy from CERT, too), the reading of this file has 10
>checks for validity. If it fails one of them, then the cache is
>rebuilt. Amongst the checks is a checksum and checking the information
>on the file using stat().
Revision 3.40 (released Friday, August 25) adds another check: it
will not create a device cache file in /tmp if the real user ID
would cause the file to be owned by root. Previously, doing an su
to root and running lsof could have created a root-owned device
cache file.
>Otherwise, it does give you a way to turn this feature off, if you are
>still unconvinced this is not so much of a problem.
You can disable the device cache file feature two ways: 1) at
compile time by disabling the HASDCACHE definition in the dialect's
machine.h header file; or 2) at run time with the -Di option.
Scott and Dr. Frederick B. Cohen, the poster of the original question
about the security of lsof's device cache file, both report having
gotten their copies of lsof from the CERT archive at cert.org.
For a long time the CERT archive copy was out of date and it was
difficult for me to arrange for it to updated.
I have now convinced the CERT archive maintainers to replace their
lsof distribution copy with a pointer to the lsof home site,
vic.cc.purdue.edu. The latest revision will always be found there
in pub/tools/unix/lsof.
There are pre-compiled binaries on vic.cc.purdue.edu, too, but I
presume no one on this list would take the risk of using one, even
though the binaries have PGP signature certificates to attest that
I built them. :-)
Vic Abell, lsof author
