Bug 23562 - RESOLV_HOST_CONF can be used to read privileged files
Summary: RESOLV_HOST_CONF can be used to read privileged files
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 7.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Aaron Brown
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2001-01-08 01:08 UTC by Gordon Messmer
Modified: 2016-11-24 15:17 UTC (History)
6 users (show)

Clone Of:
Last Closed: 2001-01-11 16:21:56 UTC

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2001:001 high SHIPPED_LIVE : glibc file read or write access local vulnerability 2001-01-11 05:00:00 UTC

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@TECHIE.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
Combine this with the exploit method I suggested earlier and you've got a
pretty plausable exploitation method.


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-
--- 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",                                                                  \

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 @@
 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
-%patch -p1
+%patch0 -p1
 ;; esac
+%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.

Note You need to log in before you can comment on or make changes to this bug.