It may be possible to write lsof's private device cache file to

system locations that are normally inaccessible to the lsof user,

depending on the UNIX dialect where lsof is installed and how that

dialect grants permission to access kernel memory information.



The vulnerability affects lsof revisions 3.18 through 3.43, installed

on these UNIX dialects:



    AIX 3.2.4, 3.2.5, 4.1,      the IBM RISC/System 6000

        4.1.1, and 4.1.2

    EP/IX 2.1.1                 the CDC 4680

    FreeBSD 1.1.5.1, 2.0, and   Intel-based systems

        2.0.5

    HP-UX 8.x, 9.x, and 10      HP systems (some combinations)

    IRIX 4.0.5H, 5.2, 5.3,      SGI systems

        6.0, and 6.1

    Linux through 1.3.0         Intel-based systems

    Motorola V/88 R32V3,        M88K systems

        R40V4.[123]

    NetBSD 1.0 and 1.0A         Intel and SPARC-based systems

    NEXTSTEP 2.1 and 3.[0123]   all NEXTSTEP architectures

    OSF/1 1.3, 2.0, 3.0, and    the DEC Alpha

        3.2

    RISC/os 4.52                MIPS R2000-based systems

    SCO OpenDesktop or          Intel-based systems

        OpenServer 1.1, 3.0,

        and 5.0

    Sequent Dynix 3.0.12        the Sequent Symmetry

    Sequent PTX 2.1.[156] and   Sequent systems

        4.0.[23]

    Solaris 2.[1234] and 2.5    Sun 4 and i86pc systems

        BETA

    SunOS 4.1.[1234]            Sun 3 and 4

    Ultrix 2.2, 4.2, 4.3,       DEC RISC and VAX

        and 4.4



I recommend that users of the affected revisions of lsof on these

dialects install lsof revision 3.44, 3.45 or later.  Section III

describes its location and some appropriate installation considerations.



- -----------------------------------------------------------------------------



I.   Description



     A private device cache file feature was introduced at lsof

     revision 3.18 to speed up subsequent calls to lsof by reducing

     the need for a full scan of the nodes in /dev (or /devices).

     Accompanying the feature was an option (-D) that allowed the

     lsof user to specify where the device cache file was to be

     recorded.



     Since lsof normally runs with effective group ID permission

     set to the group that can read kernel memory devices, the -D

     option might allow lsof to write its device cache file to a

     location not normally accessible to the real user or group

     owning the lsof process.  The locations where the lsof device

     cache file might be inappropriately recorded depend on the

     group that owns the memory devices and to what other files

     and directories the group has write permission.



     Here are two examples: 1) IBM's distribution of AIX sets group

     ownership of /dev/kmem and /etc to the "system" group and

     enables group write permission in /etc; and 2) Sun's Solaris

     distribution does the same thing, using the "sys" group.



     (Security conscious installations often create a new group --

     e.g., "kmem" or "mem" -- that owns no files and is used solely

     for enabling read access to kernel memory devices.)



     A fix for this group ID vulnerability may be found in lsof

     revisions 3.44, 3.45, and above.



     A more serious vulnerability exists when lsof must run setuid

     to the root user and also has device cache file support.  This

     happens for the lsof implementation that runs under Motorola's

     V/88 UNIX dialects R40V4.1, R40V4.2, and R40V4.3.  This gives

     the lsof user an unlimited choice of places to record the

     device cache file.  A partial fix for this vulnerability was

     introduced in lsof revision 3.43.  The complete fix may be

     found in lsof revisions 3.44, 3.45, and above.



II.  Impact



     Unauthorized users may be able to write the lsof device cache

     file to normally-restricted locations, possibly in place of

     important system files.



     The vulnerability can be exploited only by users with a valid

     account.  It cannot be exploited by arbitrary remote users.



     The vulnerability affects all lsof revisions 3.18 through 3.43

     on UNIX dialects where device cache file support has been

     implemented.



III. Solution



     Retrieve lsof revision 3.44, 3.45, or later and install it.



       Compressed tar archive:



         http://vic.cc.purdue.edu/pub/tools/unix/lsof/lsof.tar.Z



       Gzip'd tar archive:



         http://vic.cc.purdue.edu/pub/tools/unix/lsof/lsof.tar.gz



     Lsof 3.44 eliminates the vulnerability for all relevant UNIX

     dialects.  However, its overly zealous restrictions for Solaris

     and SunOS and are relaxed in revision 3.45.



     Both tar archives are wrappers that contain authentication

     information (MD5 checksums and PGP certificates) and a tar

     archive of the lsof sources.



     1.  Retrieve the wrapper archive, extract its three files --

         README.lsof_, lsof_.tar, and

         lsof_.tar.asc -- and verify its authentication

         information.  ( should be 3.44 or greater.)



     2.  Unpack the lsof source archive from lsof_.tar

         and read its documentation files.  Pay particular attention

         to the 00DCACHE file that describes options for specifying

         the location of the device cache, and the security section

         in the 00README file.



     3.  Having selected the lsof options appropriate to the UNIX

         dialect where you want to install it, run the Configure

         script, use make to build lsof, and install the resulting

         lsof executable.



- -----------------------------------------------------------------------------



Vic Abell appreciates the advice and comments provided by members

of the bugtraq mailing list that led him to realize this vulnerability

existed.  He thanks Katherine T. Fithen and Linda Hutz Pesante of the

CERT Coordination Center for their help in preparing this bulletin.