Re: Glibc Local Root Exploit
Simon Cozens [EMAIL PROTECTED] writes:
And a patch. Yeah, it's pretty obvious, but nobody's produced it yet.
Your patch doesn't include the HOSTALIASES fix (which is
security-related as well):
Index: sysdeps/generic/unsecvars.h
===
RCS file: /cvs/glibc/libc/sysdeps/generic/unsecvars.h,v
retrieving revision 1.1
retrieving revision 1.3
diff -u -d -b -r1.1 -r1.3
--- unsecvars.h 2000/09/26 09:31:25 1.1
+++ unsecvars.h 2001/01/08 17:54:58 1.3
@@ -1,11 +1,12 @@
/* Environment variable to be removed for SUID programs. */
#define UNSECURE_ENVVARS \
"GCONV_PATH", \
+ "HOSTALIASES", \
"LOCALDOMAIN", \
"LOCPATH", \
"MALLOC_TRACE",\
"NLSPATH", \
- "RESOLV_HOST_CONF" \
+ "RESOLV_HOST_CONF",\
"RES_OPTIONS", \
"TMPDIR", \
"TZDIR"
Index: resolv/res_query.c
===
RCS file: /cvs/glibc/libc/resolv/res_query.c,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -d -b -r1.15 -r1.16
--- res_query.c 2000/07/19 21:59:47 1.15
+++ res_query.c 2001/01/08 17:55:24 1.16
@@ -371,7 +371,7 @@
if (statp-options RES_NOALIASES)
return (NULL);
- file = __secure_getenv("HOSTALIASES");
+ file = getenv("HOSTALIASES");
if (file == NULL || (fp = fopen(file, "r")) == NULL)
return (NULL);
setbuf(fp, NULL);
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
Re: Glibc Local Root Exploit
Matt Zimmerman wrote:
On Thu, Jan 11, 2001 at 01:42:52AM +0200, Ari Saastamoinen wrote:
On Wed, 10 Jan 2001, Pedro Margate wrote:
install the ssh binary as suid root by default. This can be disabled
during configuration or after the fact with chmod. I believe that would
That exploit can use any suid root program which resolves host names. (For
example ping and traceroute) So you cannot fix that glibc explot only by
unsetting SUID bit of ssh client.
Or more properly, an suid root program which resolves host names _while still
holding root privileges_. ping from netkit and traceroute from LBNL do not
fall into this category. fping from SATAN, however, does.
As does OpenSSH, somthing that my patch (attached) fixes. The patch is
for OpenSSH 2.3.0p1. Special thanks to Markus Friedl
([EMAIL PROTECTED]) for his help/comments on the
patches. Tested on RedHat 7.0.
--
- mdz
Part 1.2Type: application/pgp-signature
--
Andrew Bartlett
[EMAIL PROTECTED]
--- ssh.origSat Jan 13 12:51:42 2001
+++ ssh.c Sat Jan 13 12:52:02 2001
@@ -611,12 +611,10 @@
rsh_connect(host, options.user, command);
fatal("rsh_connect returned");
}
- /* Restore our superuser privileges. */
- restore_uid();
/*
-* Open a connection to the remote host. This needs root privileges
-* if rhosts_{rsa_}authentication is enabled.
+* Open a connection to the remote host. This regains
+* root privilages as required.
*/
ok = ssh_connect(host, hostaddr, options.port,
@@ -625,6 +623,9 @@
!options.rhosts_rsa_authentication,
original_real_uid,
options.proxy_command);
+
+ /* Restore our superuser privileges. */
+ restore_uid();
/*
* If we successfully made the connection, load the host private key
--- sshconnect.orig Sat Jan 13 12:51:49 2001
+++ sshconnect.cSat Jan 13 12:52:01 2001
@@ -96,6 +96,7 @@
char *argv[10];
/* Child. Permanently give up superuser privileges. */
+ restore_uid();
permanently_set_uid(original_real_uid);
/* Redirect stdin and stdout. */
@@ -155,21 +156,22 @@
*/
if (privileged) {
int p = IPPORT_RESERVED - 1;
+ /* Restore our superuser privileges. */
+ restore_uid();
sock = rresvport_af(p, family);
+ /* Back to normal user. */
+ temporarily_use_uid(original_real_uid);
if (sock 0)
error("rresvport: af=%d %.100s", family, strerror(errno));
else
debug("Allocated local port %d.", p);
} else {
/*
-* Just create an ordinary socket on arbitrary port. We use
-* the user's uid to create the socket.
+* Just create an ordinary socket on arbitrary port.
*/
- temporarily_use_uid(original_real_uid);
sock = socket(family, SOCK_STREAM, 0);
if (sock 0)
error("socket: %.100s", strerror(errno));
- restore_uid();
}
return sock;
}
@@ -248,11 +250,7 @@
/* Create a socket for connecting. */
sock = ssh_create_socket(original_real_uid,
-#ifdef HAVE_CYGWIN
!anonymous port IPPORT_RESERVED,
-#else
- !anonymous geteuid() == 0 port IPPORT_RESERVED,
-#endif
ai-ai_family);
if (sock 0)
continue;
@@ -261,15 +259,12 @@
* hope that it will help with tcp_wrappers showing
* the remote uid as root.
*/
- temporarily_use_uid(original_real_uid);
if (connect(sock, ai-ai_addr, ai-ai_addrlen) = 0) {
/* Successful connection. */
memcpy(hostaddr, ai-ai_addr, ai-ai_addrlen);
- restore_uid();
break;
} else {
debug("connect: %.100s", strerror(errno));
- restore_uid();
/*
* Close the failed socket; there appear to
* be some problems when reusing a socket for
Re: Glibc Local Root Exploit
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
Re: Glibc Local Root Exploit
Hopefully the BUGTRAQ moderators will catch and delete my first message. This one has a little more detail. -- From: Joseph Nicholas Yarbrough [EMAIL PROTECTED] 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
Re: Glibc Local Root Exploit
On Thu, Jan 11, 2001 at 01:42:52AM +0200, Ari Saastamoinen wrote: On Wed, 10 Jan 2001, Pedro Margate wrote: install the ssh binary as suid root by default. This can be disabled during configuration or after the fact with chmod. I believe that would That exploit can use any suid root program which resolves host names. (For example ping and traceroute) So you cannot fix that glibc explot only by unsetting SUID bit of ssh client. Or more properly, an suid root program which resolves host names _while still holding root privileges_. ping from netkit and traceroute from LBNL do not fall into this category. fping from SATAN, however, does. -- - mdz PGP signature
Re Glibc local root exploit
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Greetings. Tested this on a SuSE 7.0 standard install not vulnerable I thought I'd contribute this, since I had the box standing around and some might be interested in it. Cheers - -- Si vis pacem, para bellum -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1e-SuSE (GNU/Linux) Comment: For info see http://www.gnupg.org iQH3AwUBOl11FYdXDyfNtJ+gFAMr+Ad9GUvaKEK/Fgj09psKwqIAvlAc+KMOatci gZrAt4GBIJYYr61yfrV5KwA0kPiRplMmk7d86w8bLVU2YBf/oY+S+0RqhEZM2o7I Iy347d+W+/3nGoF4E4H4U+0TXHa45eFw4LCU/sN6sRvWbdGVv1WjXd0bXk3VWiSC AueK4ODHBpfYMCI7dDuUmF4LKBSbD1MDXPhndKs+Q4LEQ1ZNRhR8fjznKTPTDsuc pgPka7DFXdKclUcish8txoI8vvAS0Rqz7FJQrEZ7GX3eTYAOiPIbl7CzfTFG3iKZ VJqu626urBG55CJoY+mjXyxklWb6iLF2B391+Evz5yUCrxvoj1ghqbQl9JDCoy9G v4jX8R8cQbpECkPtsBze5NQScG7PhUJyTbjNheONMpQCWamOcIN0IXnI2IlLdYfj 4anr3O/AkXr017CXMNN01DrTCRNnmfaLbbzHAsMsQ8kAqd20S+IEijDkO7DCK1MM mtgt3bsvu6JM+tRM5/+xK3JMdlZCfFGK6POjcXjucvZEtKpmE2X9048GsBJJp3u6 IUDWfRgOZyGqKH3XULJO3FXfJGBVi3ga/8hZRPxtUC/SUCTdE6UyaIek2S5UvmBP wP85kV7IUi9eVpm4Q3pvSebBi4yyM3KoPDg= =fv4L -END PGP SIGNATURE-
Re: Glibc Local Root Exploit
On Wed, 10 Jan 2001, Digital Overdrive wrote:
[Credits to ^herman^ in #hit2000 on ircnet]
A temp. sollution is to place this in /etc/services:
Erm, you mean /etc/profile?
declare -r RESOLV_HOST_CONF
jan@flits102-93:~$ export RESOLV_HOST_CONF=/etc/shadow
bash: RESOLV_HOST_CONF: readonly variable
jan@flits102-93:~$
Oooh, try that:
$ bash --norc --noprofile -c 'RESOLV_HOST_CONF=/etc/shadow ssh host'
--
___
Michal Zalewski [[EMAIL PROTECTED]] [tp.internet/security]
[http://lcamtuf.na.export.pl] =--= bash$ :(){ :|:};:
=--= Did you know that clones never use mirrors? =--=
Re: Glibc Local Root Exploit
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 \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
Re: Glibc Local Root Exploit
This does not happen on my machine using glibc-2.2 and openssh-2.3.0p1 following your example. Tom Veldhouse [EMAIL PROTECTED] - Original Message - From: "Charles Stevenson" [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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
Re: Glibc Local Root Exploit
Greetings, The implementations of ssh that I'm familiar with (ssh and OpenSSH) install the ssh binary as suid root by default. This can be disabled during configuration or after the fact with chmod. I believe that would prevent this exploit from operating. I've turned off the suid bit on every ssh installation I've performed and it seems to work the same. I'm not sure what reason ssh has to be suid root, nobody I've asked has any idea. Regards, Pedro On Wed, 10 Jan 2001, 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. 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
Re: Glibc Local Root Exploit
Summary of responses: -- From: Jag [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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-x1 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:9:7:::134537268' /etc/shadow: line 2: bad command `bin:x:10679:0:9:7:::' /etc/shadow: line 3: bad command `daemon:x:10679:0:9:7:::' /etc/shadow: line 4: bad command `adm:x:10679:0:9: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-x1 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 [EMAIL PROTECTED] Tested on Debian 2.2 (potato) with OpenSSH-1.2.3 and libc6 2.1.3: does not work. -- From: Michael Devogelaere [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] [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). :-)
Re: Glibc Local Root Exploit
on 1/10/01 1:34 PM, KraZee . at [EMAIL PROTECTED] wrote: Hello, I run a few slackware boxes and I've tested this vulnerability. Is there a patch? I haven't seen any vendor patches for this problem yet. I'm also wondering if this hole is only limited to suids that use environmental variables (ssh?), the reason I ask is because I was only able to duplicate the bug by running ssh as root, since its not suid on my systems it didnt read /etc/shadow. Thanks and I look forward to your reply. In resolv/res_hconf.c, in the function _res_hconf_init, replace the getenv call for ENVHOST iirc, (#define for RESOLV_HOST_CONF), with __secure_getenv. Also I would like to say thanks to Jakub Jelinek as Ben Collins pointed out my error. New packages for Yellow Dog 2.0 prerelease, for those of you testing should be in ruffpack very soon now. In the mean time I would suggest changing the permissions on all suid/sgid binaries that do host name lookups. Or some of the other fine suggestions that have been posted. As has been pointed out this is an old bug that was fixed and has come back. Cheers, Charles Stevenson - Mark -- On Wed, 10 Jan 2001 00:06:48 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. 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 Get FREE Email/Voicemail with 15MB at Lycos Communications at http://comm.lycos.com
Re: Glibc Local Root Exploit
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\ [EMAIL PROTECTED] | [EMAIL PROTECTED] /( )\ ^^-^^
Re: Glibc Local Root Exploit
On Wed, 10 Jan 2001, Pedro Margate wrote: install the ssh binary as suid root by default. This can be disabled during configuration or after the fact with chmod. I believe that would That exploit can use any suid root program which resolves host names. (For example ping and traceroute) So you cannot fix that glibc explot only by unsetting SUID bit of ssh client. every ssh installation I've performed and it seems to work the same. I'm not sure what reason ssh has to be suid root, nobody I've asked has any idea. By default ssh client makes connection from source socket 1024, and it is impossible without root privileges. When you run the client as non root, source socket will be 1023, but man can disable this kind of connections by configuring the ssh daemon. -- Ari Saastamoinen [EMAIL PROTECTED]
Re: Glibc Local Root Exploit
ssh is installed SUID root so that you can use RHOSTS authentication. Like rlogin and rsh, rhosts authentication only succeeds if the remote connection was opened on a privileged port, that is, under 1024 (the protocols may be more specific than that). The theory is that if a remote machine connects to the server, _and_ that machine is listed as a trusted host, _and_ the connection originated on a privileged port, then the server can accept a connection given only a username because: the program opening the connection must be either run by root, or a SUID application. If it's SUID, then it's the system rlogin or rsh or ssh binary; users can't make SUID root binaries. If it's the system binary, then it will only give the username of the person that ran the program, so they can't "lie" about their identity. As bad as rhosts style authentication is, it's still used in a lot of places. As long as you aren't using RHOSTS style authentication, then ssh should continue to work in the default configuration. I'm not sure there is such a recourse for rlogin or rsh. In any case, removing SUID from ssh isn't a good fix, since any other SUID root application that resolves hostsnames will still be affected (like rsh or rlogin ;) On Wed, 10 Jan 2001, Pedro Margate wrote: The implementations of ssh that I'm familiar with (ssh and OpenSSH) install the ssh binary as suid root by default. This can be disabled during configuration or after the fact with chmod. I believe that would prevent this exploit from operating. I've turned off the suid bit on every ssh installation I've performed and it seems to work the same. I'm not sure what reason ssh has to be suid root, nobody I've asked has any idea. -- If I had a dollar for every brain that you don't have, I'd have one dollar. - Squidward to SpongeBob
Re: Glibc Local Root Exploit
On Wed, 10 Jan 2001, 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 Exploit discovered discussed and fixed circa August 1996. Original Announcement: http://www.securityfocus.com/templates/archive.pike?list=1mid=5222 Discussion thread: http://www.securityfocus.com/templates/archive.pike?end=2001-01-13start=2001-01-07tid=5239threads=0list=1; -- Joe Technical Support General Support: [EMAIL PROTECTED] Blarg! Online Services, Inc. Voice: 425/401-9821 or 888/66-BLARGhttp://www.blarg.net
Re: Glibc Local Root Exploit
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\ [EMAIL PROTECTED] | [EMAIL PROTECTED] /( )\ ^^-^^
Re: Glibc Local Root Exploit
In bash, simplest way to discourage idiots who are going to do this is to put the following in /etc/bashrc or /etc/profile (if you use Bash, I dont know about tcsh or the others): readonly RESOLV_HOST_CONF="" Its not fool-proof, and wont last long, and definately wont stop those intent on doing damage, but hopefully this problem will get fixed quickly... Brian Bruns Valley Of The Mage Consulting http://www.magenet.com ICQ: 8077511 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. 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 S/MIME Cryptographic Signature
Re: Glibc Local Root Exploit
Pedro Margate said the following on Wed, Jan 10, 2001 at 01:40:39PM -0500, The implementations of ssh that I'm familiar with (ssh and OpenSSH) install the ssh binary as suid root by default. This can be disabled during configuration or after the fact with chmod. I believe that would prevent this exploit from operating. I've turned off the suid bit on every ssh installation I've performed and it seems to work the same. I'm not sure what reason ssh has to be suid root, nobody I've asked has any idea. If you have the following options set in ssh_config RhostsAuthentication yes RhostsRSAAuthentication yes UsePrivilegedPort yes then ssh will connect from a privileged port, which requires root privileges. Jerry Connolly, Eircom.net CIRT -- ejrry^[bxpZZ
Re: Glibc Local Root Exploit (summary)
Thanks to everyone who replied to my post regarding ssh, although all that was necessary was to simply smack me upside the head with a manual or FAQ. (You don't have to anymore, I already did that myself) To summarize what I have learned: - ssh is suid root so that it can bind to low-numbered ports, allowing it to work using .shosts or .rhosts authentication. - glibc is the real problem, not ssh. Any suid program that uses the resolver would be affected by this exploit. This should have been obvious to me. Sorry for my hastily written post. It just goes to show that haste makes, well, you know... Regards, Pedro
