Red Hat Bugzilla – Bug 23562
RESOLV_HOST_CONF can be used to read privileged files
Last modified: 2016-11-24 10:17:37 EST
Just got a message from the Vuln-dev list @securityfocus.com that reads: -- Date: Sat, 6 Jan 2001 17:23:35 -0500 From: Techno Bob <tbob@TECHIE.COM> To: "VULN-DEV@SECURITYFOCUS.COM" <VULN-DEV@SECURITYFOCUS.COM> Subject: Re: traceroute-4.4BSD (slack) heap overflow ------Original Message------ Yep, I know, that's exactly why I posted it here, because I found no proper way to exploit it, even by modifying /etc/hosts :) Btw, isn't there any environment variable that allows you to specify the hosts file being used? ------------------------------- Yep, try this: $ export RESOLV_HOST_CONF= any file you want And this can be done by user-level because this used to be a way to view /etc/shadow. Combine this with the exploit method I suggested earlier and you've got a pretty plausable exploitation method. Thanx TBob -- Ping and traceroute didn't allow me to exploit this flaw, but ssh did. Apparently, this is still a flaw in glibc, although "Techno Bob" called it a "used to be" problem. All environment variables that will cause glibc to open a file should be unset by the loader, like LD_LIBRARY_PATH. Could someone fix glibc so that RESOLV_HOST_CONF and all others are unset?
Will be fixed soonish (as soon as packages are built and QA tests it all).
Don't really know how bugzilla works yet. This is what I used as a patch: diff -uNr glibc-2.2.orig/sysdeps/generic/unsecvars.h glibc- 2.2/sysdeps/generic/unsecvars.h --- glibc-2.2.orig/sysdeps/generic/unsecvars.h Thu Jan 11 16:09:25 2001 +++ glibc-2.2/sysdeps/generic/unsecvars.h Thu Jan 11 10:17:16 2001 @@ -5,7 +5,7 @@ "LOCPATH", \ "MALLOC_TRACE", \ "NLSPATH", \ - "RESOLV_HOST_CONF" \ + "RESOLV_HOST_CONF", \ "RES_OPTIONS", \ "TMPDIR", \ "TZDIR" And then for the spec file: --- glibc.spec.orig Thu Jan 11 16:12:15 2001 +++ glibc.spec Thu Jan 11 16:17:03 2001 @@ -27,7 +27,8 @@ %endif Prereq: basesystem Conflicts: rpm <= 4.0-0.65 -Patch: glibc-kernel-2.4.patch +Patch0: glibc-kernel-2.4.patch +Patch1: glibc-unsecvars.patch %if %{linux24} ExcludeArch: ia64 Conflicts: kernel < 2.4.0 @@ -117,9 +118,10 @@ # are ever run case `uname -r` in [01].*|2.[0-3]*) -%patch -p1 +%patch0 -p1 ;; esac %endif +%patch1 -p1 -b .unsecvars %ifarch armv4l sparc64 ia64 rm -rf glibc-compat Didn't increment version - fixed it for me.
This patch fixes just 1 of the several security issues which will be fixed by glibc-2.2-12 QA is testing at the moment.