Bugtraq mailing list archives

Re: -rw-rw-rw- 1 root 8025 Aug 24 04:10 /tmp/.lsof_dev_cache


From: abe () vic cc purdue edu (Vic Abell)
Date: Mon, 28 Aug 1995 11:13:44 -0500


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



Current thread: