Bug 23562

Summary:	RESOLV_HOST_CONF can be used to read privileged files
Product:	[Retired] Red Hat Linux	Reporter:	Gordon Messmer <gordon.messmer>
Component:	glibc	Assignee:	Jakub Jelinek <jakub>
Status:	CLOSED ERRATA	QA Contact:	Aaron Brown <abrown>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.0	CC:	dr, fweimer, jarno.huuskonen, pekkas, pnasrat, pspencer
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-01-11 16:21:56 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Gordon Messmer 2001-01-08 01:08:44 UTC

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>
To: "VULN-DEV" <VULN-DEV>
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?

Comment 1 Jakub Jelinek 2001-01-08 19:09:57 UTC

Will be fixed soonish (as soon as packages are built and QA tests it all).

Comment 2 Paul Nasrat 2001-01-11 16:18:55 UTC

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.

Comment 3 Jakub Jelinek 2001-01-11 16:21:52 UTC

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.