Peanuts NeXT Software Archives/Peanuts-1.iso/NeXTanswers/Files/Security/2031_CA-VB-95:07-lsof_private_data_cache.txt

Text File | 1995-10-03 | 7.5 KB | 183 lines

======================================================================
CERT Vendor-Initiated Bulletin VB-95:07
September 28, 1995

Topic:  Directory and file vulnerability from lsof 3.18 through 3.43
Source: Vic Abell ([e-mail])

To aid in the wide distribution of essential security information, the CERT
Coordination Center is forwarding the following information from Vic Abell,
who urges you to act on this information as soon as possible.  Please contact
Vic Abell if you have any questions or need further information.

========================FORWARDED TEXT STARTS HERE============================

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:

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

       Gzip'd tar archive:

         ftp://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_<revision>, lsof_<revision>.tar, and
         lsof_<revision>.tar.asc -- and verify its authentication
         information.  (<revision> should be 3.44 or greater.)

     2.  Unpack the lsof source archive from lsof_<revision>.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.

=========================FORWARDED TEXT ENDS HERE=============================


CERT publications, information about FIRST representatives, and
other information related to computer security are available for anonymous
FTP from info.cert.org.

CERT advisories and bulletins are also posted on the USENET newsgroup
comp.security.announce. If you would like to have future advisories and
bulletins mailed to you or to a mail exploder at your site, please send mail
to [e-mail].

If you wish to send sensitive incident or vulnerability information to
CERT staff by electronic mail, we strongly advise that the e-mail be
encrypted.  The CERT Coordination Center can support a shared DES key, PGP
(public key available via anonymous FTP on info.cert.org), or PEM (contact
CERT staff for details).

Internet email: [e-mail]
Telephone: [phone] (24-hour hotline)
           CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4),
           and are on call for emergencies during other hours.
Fax: [phone]

CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
USA

CERT is a service mark of Carnegie Mellon University.