lsof.txt

1999-08-17T00:00:00
ID PACKETSTORM:12233
Type packetstorm
Reporter HERT
Modified 1999-08-17T00:00:00

Description

                                        
                                            `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  
  
`