Date: Thu, 18 Feb 1999 12:24:52 -0500
From: Gene Spafford <spaf@CS.PURDUE.EDU>
To: BUGTRAQ@netspace.org
Subject: Re: [HERT] Advisory #002 Buffer overflow in lsof

People who publish bugs/exploits that are not being actively exploited
*before* giving the vendor a chance to fix the flaws are clearly
grandstanding.  They're part of the problem -- not the solution.

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

Date: Thu, 18 Feb 1999 17:11:41 -0700
From: Theo de Raadt <deraadt@CVS.OPENBSD.ORG>
To: BUGTRAQ@netspace.org
Subject: Re: [HERT] Advisory #002 Buffer overflow in lsof

> People who publish bugs/exploits that are not being actively exploited
> *before* giving the vendor a chance to fix the flaws are clearly
> grandstanding.  They're part of the problem -- not the solution.

No.  The problem is badly written code.

It takes me about 2 minutes to find bugs in security related software.

I am assuming that I'm not the only person looking for these kinds of
bugs.

The REAL problem is software package maintainers who do not proactively
audit their software.

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

Date: Thu, 18 Feb 1999 16:43:26 -0500
From: Vic Abell <abe@purdue.edu>
To: BUGTRAQ@netspace.org
Subject: Re: [HERT] Advisory #002 Buffer overflow in lsof

Don Lewis writes:
>
> On Feb 18,  1:30am, "Anthony C . Zboralski" wrote:
> } Subject: [HERT] Advisory #002 Buffer overflow in lsof
>
> }    When lsof is setuid-root or setgid kmem, it is vulnerable to a buffer
> }    overflow that will lead to direct root compromise or root compromise
> }    thru live kernel patching.
>
> If lsof is installed setgid kmem, it shouldn't gain any privileges to
> overwrite something to gain root access.  At worst, it should only be
> possible to read things in kernel memory that ordinary users shouldn't
> have access to (I suppose this might include a password in a tty buffer
> if the cracker got really lucky).
>
> ... or are there systems that give group kmem write privileges?  If so,
> I'd say that's a security hole.

I'd say the /dev/kmem warning is over-stated.  Most systems don't
give the group that can read /dev/kmem write permission.

However, some systems at times have used the same group ownership
for /dev/kmem and important system directories, AND made those
directories and some of their files group writeable.  In that case
a stack attacked lsof might be able to do file or directory damage.

There are three lsof installations that could be setuid(root):
Pyramid DC/OSx lsof, /proc-based Linux lsof (generally Linux kernels
2.1.72 and above), and Pyramid Reliant UNIX lsof.  (I've tried to
limit the number of dialects that need setuid(root) permission.)

Lsof drops its set[gu]id permissions as soon as possible.

Vic Abell <abe@purdue.edu>, lsof author

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

Date: Thu, 18 Feb 1999 21:41:16 -0500
From: Gene Spafford <spaf@CS.PURDUE.EDU>
To: BUGTRAQ@netspace.org
Subject: Re: [HERT] Advisory #002 Buffer overflow in lsof

> The REAL problem is software package maintainers who do not proactively
> audit their software.

That some vendors miss problems, or that software in widespread legacy use is
suddenly found to be vulnerable to a flaw is still not a reason to widely
publish a description of a potential attack before the vendor is notified.

Yes, some software could be written better.  Yes, some vendors may do a poor
job of responding to reports.

Still, posting attacks or vulnerabilities that are in not in general
knowledge and are not being actively exploited and *before* the vendor has
been given a chance to respond is not being part of the solution.   It is
arrogance or showing off.

People who really want to improve security find ways to avoid hurting victims
and increase protection.   If there is a problem that is not known and not
under attack, notifying the vendor and waiting for a valid fix to appear is
not going to result in anyone being hurt.   Posting an exploit widely for a
previously unknown problem suddenly opens up all the current users to attack.

That there is (perhaps) a problem in assurance does not forgive this problem.
 Two wrongs do not make a right.

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

Date: Thu, 18 Feb 1999 01:41:26 +0100 (CET)
From: Anthony C. Zboralski <acz@hert.org>
To: alert-outgoing@plan9.hert.org

Subject: [HERT] Advisory #002 Buffer overflow in lsof 4.40
>From acz@plan9.hert.org  Thu Feb 18 01:12:38 1999
Received: from localhost (acz@localhost)
        by plan9.hert.org (8.9.1a/8.9.1) with ESMTP id BAA06236
        for <alert-outgoing@hert.org>; Thu, 18 Feb 1999 01:12:38 +0100 (CET)
Date: Thu, 18 Feb 1999 01:12:38 +0100 (CET)
>From: "Anthony C. Zboralski" <acz@hert.org>
To: alert-outgoing@hert.org
Message-ID: <Pine.BSF.4.03.9902180107440.11533-100000@plan9.hert.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

-----BEGIN PGP SIGNED MESSAGE-----

- --------------------------------------------------------------
  HERT - Hacker Emergency Response Team
  alert@hert.org - http://www.hert.org

  Advisory:        #00002
  Title:           lsof
  Date:            17 February 1999 
  Summary:         Buffer overflow in lsof version 4.40 and prior
  IMPACT:          Local users may obtain root priviledge.

  Author:          Mariusz Tmoggie Marcinkiewicz <tmoggie@hert.org>
  Test Exploit:    kil3r@hert.org
- ---------------------------------------------------------------

Copyright (C) 1999 Hacker Emergency Response Team

Permission is granted to reproduce and distribute HERT advisories in their
entirety, provided the HERT PGP signature is included and provided the alert is used for noncommercial
purposes and with the intent of increasing the aware-
ness of the Internet community.

This advisory is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

1. Background:

   lsof - list open files
   Lsof lists information about files opened by processes for most
   UNIX dialects.

   When lsof is setuid-root or setgid kmem, it is vulnerable to a buffer
   overflow that will lead to direct root compromise or root compromise
   thru live kernel patching.

   The paradox is that lsof is a great security tool for administrators and
   we encourage its uses as long as it is NOT setuid-root or setgid.
   
   Test exploit code for this vulnerability was developped by kil3r@hert.org
   and will be made available to lsof author, HERT collaborators, sponsors
   and partners.

2. Distributions known to be affected.

   OpenBSD 2.4's ports facility retrieves and builds lsof package setgid kmem.
   FreeBSD's ports facility retrieves and builds lsof package setgid kmem.
   SuSe Linux ships lsof setgid kmem.
   Debian GNU/Linux 2.0 ships lsof setgid kmem.
   Redhat Linux 5.2 ships lsof setgid kmem.

3. Recommendations

   Fix:
     
     chmod 0755 lsof

To subscribe to the HERT Alert mailing list, email alert@hert.org
with subscribe in the body of the message.

Contact hert@hert.org for more information.
The HERT PGP public key is available at ftp://ftp.hert.org/pub/HERT_PGP.key

To report a vulnerability: http://www.hert.org/vul_reporting_form

We would like to thank the individuals who donates some of their time to HERT. 

HERT is a non-profit international organisation based in France.
If you wish to join the HERT effort please send a note to hert@hert.org.
- --
Please respect the privacy of this mailing list.
To UNSUBSCRIBE, email to hert-private-request@hert.org
with "unsubscribe" in the body. Trouble? Contact listmaster@hert.org

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1

iQCVAwUBNss8D7iV3oeHg1NdAQGHZwP+L76JOU2iHtvl2i3AHP3VDdEJ6W8M5zjf
vVWDpQY7z4qmW4Ai/D5mnzeRwUey8W9imkoY4J4cF3/O+s/70+rsbwAKsmVgztBm
DjhdWfMl/yz0ZT8zATJV+YVGtPQsmzvPbZR7YWOQh7oQQyPwzQXkswHkTB24Fsdg
ehmkQnF1N9c=
=Ohr4
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to alert-request@hert.org
with "unsubscribe" in the body. Trouble? Contact listmaster@hert.org

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

Date: Thu, 18 Feb 1999 07:10:47 -0500
From: Vic Abell <abe@purdue.edu>
To: BUGTRAQ@netspace.org
Subject: Re: [HERT] Advisory #002 Buffer overflow in lsof

I would have appreciated the courtesy of an advance notice
that this problem had been discovered.  5 minutes after I
learned of it *third-hand* via DejaNews this patch was
available and announced to the lsof-l mailing list:

ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/patches/4.40/arg.c.patch

Vic Abell <abe@purdue.edu>, lsof author

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

Date: Thu, 18 Feb 1999 11:29:51 -0800
From: Lamont Granquist <lamontg@RAVEN.GENOME.WASHINGTON.EDU>
To: BUGTRAQ@netspace.org
Subject: Re: [HERT] Advisory #002 Buffer overflow in lsof

Since this is a buffer overflow in enter_uid() which is called out of
main() the operating systems which have the RA lower on the stack and
require two returns will not be vulnerable to this.  That means that this
bug is not exploitable on Digital Unix, Solaris/sparc and IRIX(?).  It
would be exploitable in principle on Solaris/x86 and on any other O/S with
the RA above the stack.

Digital Unix, Solaris and IRIX to my knowledge don't ship with lsof, but
admins may have installed them suid or sgid in /usr/local/bin...

--
Lamont Granquist                       lamontg@raven.genome.washington.edu
Dept. of Molecular Biotechnology       (206)616-5735  fax: (206)685-7344
Box 352145 / University of Washington / Seattle, WA 98195
PGP pubkey: finger lamontg@raven.genome.washington.edu | pgp -fka

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

Date: Thu, 18 Feb 1999 08:31:33 -0800
From: Don Lewis <Don.Lewis@TSC.TDK.COM>
To: BUGTRAQ@netspace.org
Subject: Re: [HERT] Advisory #002 Buffer overflow in lsof

On Feb 18,  1:30am, "Anthony C . Zboralski" wrote:
} Subject: [HERT] Advisory #002 Buffer overflow in lsof

}    When lsof is setuid-root or setgid kmem, it is vulnerable to a buffer
}    overflow that will lead to direct root compromise or root compromise
}    thru live kernel patching.

If lsof is installed setgid kmem, it shouldn't gain any privileges to
overwrite something to gain root access.  At worst, it should only be
possible to read things in kernel memory that ordinary users shouldn't
have access to (I suppose this might include a password in a tty buffer
if the cracker got really lucky).

... or are there systems that give group kmem write privileges?  If so,
I'd say that's a security hole.

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

Date: Fri, 19 Feb 1999 02:03:54 +0100
From: Mariusz Marcinkiewicz <many@ENSI.NET>
To: BUGTRAQ@netspace.org
Subject: Re: [HERT] Advisory #002 Buffer overflow in lsof

On Thu, 18 Feb 1999, Don Lewis wrote:

> ... or are there systems that give group kmem write privileges?  If so,
> I'd say that's a security hole.

Yes, you are right... but... I saw that hole after installing new linx and
checked it's security. First I was suprised but not for a long time.
In a few mins I noticed all linux versions are chown .kmem; chmod g+s
lsof...  on linux /dev/kmem is +w for gid kmem, on bsd too (probably, I
didn't checked that), so... all of std. distributions are vuln. without
ONE! the slackware, IMHO, it's the most secure distribution [ :))) i know:
slackware doesn't has lsof;))) but by tahat way that distr. is secure ;P ]

Cheers

--
Mariusz Marcinkiewicz [Security Specialist] [many@ensi.net]
European Network Security Institute [http://www.ensi.net]

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

Date: Thu, 18 Feb 1999 16:46:17 -0800
From: route@RESENTMENT.INFONEXUS.COM
To: BUGTRAQ@netspace.org
Subject: Re: [HERT] Advisory #002 Buffer overflow in lsof

[Gene Spafford wrote]
|
| People who publish bugs/exploits that are not being actively exploited
| *before* giving the vendor a chance to fix the flaws are clearly
| grandstanding.  They're part of the problem -- not the solution.
|

    Who is to say the vulnerability in question was NOT being exploited
    prior to release?  Odds are it was.  Bugtraq is a full-diclosure list.
    The `problem` as you succinctly put it is in *non-disclosure*.  While
    it is still questionable whether or not the original posters found the bug
    themselves (the advisory lacked any technical detail) calling them part of
    the problem is a misfire of your disdain (attacking them on the content
    of the advisory --or lack thereof-- is a much better call).  The problem,
    in this case, would be the malevolent individual(s) breaking into your
    machine exploiting this bug (before or after it was disclosed).

    Don't shoot the messenger.
--
I live a world of paradox... My willingness to destroy is your chance for
improvement, my hate is your faith -- my failure is your victory, a victory
that won't last.

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

-----BEGIN PGP SIGNED MESSAGE-----

We have received reports that the lsof package is distributed in
Debian GNU/Linux 2.0 contains a buffer overflow. Using this overflow
it is possible for local users to gain root-access. We have fixed
this problem in version 4.37-3.

We recommend you upgrade your lsof package immediately.

wget url
        will fetch the file for you
dpkg -i file.deb
        will install the referenced file.

Debian GNU/Linux 2.0 alias hamm
- -------------------------------

  This version of Debian was released only for the Intel and the
  Motorola 68xxx architecture.


  Source archives:
    ftp://ftp.debian.org/debian/dists/proposed-updates/lsof_4.37-3.diff.gz
      MD5 checksum: d85b3e241693c64c64a523dbc36227ef
    ftp://ftp.debian.org/debian/dists/proposed-updates/lsof_4.37-3.dsc
      MD5 checksum: 55472cf9e28bddc396ddda653b064a29
    ftp://ftp.debian.org/debian/dists/proposed-updates/lsof_4.37.orig.tar.gz
      MD5 checksum: af883ff0eb3b1c0f0134a79f18158257

  Intel architecture:
    ftp://ftp.debian.org/debian/dists/proposed-updates/lsof-2.0.35_4.37-3_i386.deb
      MD5 checksum: e91000cbaaf9661a1fbb1a268fb5cf7b

  Motorola 680x0 architecture:
    ftp://ftp.debian.org/debian/dists/proposed-updates/lsof-2.0.36_4.37-3_m68k.deb
      MD5 checksum: 09aa6eccd186a12aeb152f265e37c8b2


  These files will be moved into
  ftp://ftp.debian.org/debian/dists/hamm/*/binary-$arch/ soon.


For not yet released architectures please refer to the appropriate
directory ftp://ftp.debian.org/debian/dists/sid/binary-$arch/ .

- --
Debian GNU/Linux      .    Security Managers     .   security@debian.org
              debian-security-announce@lists.debian.org
  Christian Hudon     .     Wichert Akkerman     .     Martin Schulze
<chrish@debian.org>   .   <wakkerma@debian.org>  .   <joey@debian.org>

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQB1AwUBNtcR4ajZR/ntlUftAQFVBgMAg0A/HjleQ3ljBjggOVQ4VEGvkV8WP6Y6
/N9Jak7HP2Wy8hG7W/Wq5cZ0+JWwLPNDv6MbPItCCuIrC8803hm5ie6hpiAo8fiS
o/xS6VcJTeBGxF/2UXz7vvS7AA/FuaNc
=g5Hf
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-security-announce-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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

Date: Fri, 5 Mar 1999 21:37:42 +0100
From: Mario Lorenz <ml@VDAZONE.ORG>
To: BUGTRAQ@netspace.org
Subject: Re: Linux /usr/bin/gnuplot overflow -- SuSE hasnt fixed lsof              either

On 05. Mar 1999, at 14:22:45 wrote Hans-Bernhard Broeker:

[gnuplot stuff deleted]

>
> I strongly second this recommendment. I'll mail S.u.S.E. about it, if
> no-one else does (but then, they're bound to have someone reading bugtraq,
> right?).

Not necessarily. SuSE has still not fixed the lsof buffer overflow either,
even though lsof is setgid kmem and /dev/kmem is group writable (!)
I mailed them earlier this week and got as response that they have a new
lsof which unfortunately would require kernel 2.2. As quick fix they suggested
removing the group write permissions from /dev/kmem....
As far as I could check this applies to SuSE 5.3 and 6.0.

--
Mario Lorenz                            Internet:    <ml@vdazone.org>
                                        Ham Radio:   DL5MLO@OK0PKL.#BOH.CZE.EU