Bug 23562 - RESOLV_HOST_CONF can be used to read privileged files
RESOLV_HOST_CONF can be used to read privileged files
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Aaron Brown
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-01-07 20:08 EST by Gordon Messmer
Modified: 2016-11-24 10:17 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-01-11 11:21:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gordon Messmer 2001-01-07 20:08:44 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?
Comment 1 Jakub Jelinek 2001-01-08 14:09:57 EST
Will be fixed soonish (as soon as packages are built and QA tests it all).
Comment 2 Paul Nasrat 2001-01-11 11:18:55 EST
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 11:21:52 EST
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.