exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

S-95-16.asc

S-95-16.asc
Posted Jan 10, 2000

Subject vulnerability in lsof versions 3.18 - 3.43 Date 29-Sep-95

SHA-256 | fa2837e6db90f71e3de5a1bfeda5c0d9e3e226faf78a48acca729ff71da681c6

S-95-16.asc

Change Mirror Download
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

===============================================================================
>> CERT-NL, 01-Mar-2000 <<
>> All CERT-NL information has been moved to http://cert.surfnet.nl. Links <<
>> to CERT-NL information contained in this advisory are therefore outdated. <<
>> <<
>> CERT-NL also has stopped the CERT-CC-Mirror service. Due to this the <<
>> links to the CERT-CC mirror are obsolete. Visit the CERT-CC site for the <<
>> complete CERT-CC advisory texts: http://www.cert.org <<
===============================================================================
===============================================================================
Security Advisory CERT-NL
===============================================================================
Author/Source : Don Stikvoort Index : S-95-16
Distribution : World Page : 1
Classification: External Version: 1
Subject : vulnerability in lsof versions 3.18 - 3.43 Date : 29-Sep-95
===============================================================================

By courtesy of CERT Coordination Center we received the following information
about a vulnerability in lsof versions 3.18 - 3.43 .

If this applies to you, upgrade your lsof version.

Verbatim now:

===============================================================================

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 (abe@cc.purdue.edu)

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-NL is the Computer Emergency Response Team for SURFnet customers. SURFnet
is the Dutch network for educational, research and related institutes. CERT-NL
is a member of the Forum of Incident Response and Security Teams (FIRST).

All CERT-NL material is available under:
http://cert.surfnet.nl/

In case of computer or network security problems please contact your local
CERT/security-team or CERT-NL (if your institute is NOT a SURFnet customer
please address the appropriate (local) CERT/security-team).

CERT-NL is one/two hour(s) ahead of UTC (GMT) in winter/summer,
i.e. UTC+0100 in winter and UTC+0200 in summer (DST).

Email: cert-nl@surfnet.nl ATTENDED REGULARLY ALL DAYS
Phone: +31 302 305 305 BUSINESS HOURS ONLY
Fax: +31 302 305 329 BUSINESS HOURS ONLY
Snailmail: SURFnet bv
Attn. CERT-NL
P.O. Box 19035
NL - 3501 DA UTRECHT
The Netherlands

NOODGEVALLEN: 06 22 92 35 64 ALTIJD BEREIKBAAR
EMERGENCIES : +31 6 22 92 35 64 ATTENDED AT ALL TIMES
CERT-NL'S EMERGENCY PHONENUMBER IS ONLY TO BE USED IN CASE OF EMERGENCIES:
THE SURFNET HELPDESK OPERATING THE EMERGENCY NUMBER HAS A *FIXED*
PROCEDURE FOR DEALING WITH YOUR ALERT AND WILL IN REGULAR CASES RELAY IT
TO CERT-NL IN AN APPROPRIATE MANNER. CERT-NL WILL THEN CONTACT YOU.
===============================================================================

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1i

iQA/AwUBOL6IFzSYjBqwfc9jEQIpkgCdFOFmDg4zSKxkeQIbIO5t7FVM+mMAoJq2
sZPbF239ctN/FVfobFqP6JTy
=RAgk
-----END PGP SIGNATURE-----
Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close