Date: Thu, 18 Feb 1999 12:24:52 -0500 From: Gene Spafford 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 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 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 , lsof author ------------------------------------------------------------------------ Date: Thu, 18 Feb 1999 21:41:16 -0500 From: Gene Spafford 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 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 ; Thu, 18 Feb 1999 01:12:38 +0100 (CET) Date: Thu, 18 Feb 1999 01:12:38 +0100 (CET) >From: "Anthony C. Zboralski" To: alert-outgoing@hert.org Message-ID: 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 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 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 , lsof author ------------------------------------------------------------------------ Date: Thu, 18 Feb 1999 11:29:51 -0800 From: Lamont Granquist 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 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 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 . . -----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 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: Ham Radio: DL5MLO@OK0PKL.#BOH.CZE.EU