[1112] in linux-security and linux-alert archive
Environment Variables (Was Re: [linux-security] Re: RESOLV_HOST_CONF )
daemon@ATHENA.MIT.EDU (Mark Whitis)
Thu Aug 29 19:26:54 1996
Date: Thu, 29 Aug 1996 00:35:00 -0400 (EDT)
From: Mark Whitis <whitis@dbd.com>
To: Daniel Bromberg <ddaniel@furlong.jpl.nasa.gov>
cc: Joshua Cowan <jcowan@jcowan.reslife.okstate.edu>,
linux-security@tarsier.cv.nrao.edu
In-Reply-To: <199608260046.RAA04384@furlong.jpl.nasa.gov>
On Sun, 25 Aug 1996, Daniel Bromberg wrote:
> I propose a blanket solution: have the kernel manipulate the
> environment passed to the setuid program in a safe manner. Thus only
> pass through a few, if any, env variables to any setuid program,
> statically linked or not. (Off the top of my head, all I think one
> needs is USER, HOME, possibly HOSTALIASES). Given the splitvt type of
> attack, we'd also need to 'clean up' the ones we do pass through, by
> removing non-printable content and limiting the length. There is more
> configuration needed: so there could be some file like
> /etc/default/root.env which contains the environment that the sysadmin
> deems adequate for proper operation of all setuid programs. (like
> PATH, HOSTNAME, etc.) Such a file could also specify which user's env
> variables were safe to pass through.
Last time I looked at possibilities for exploits of environment variables
on setuid programs (or via telnetd), I came to the conclusion that
virtually all environment variables, even the "safe" (and sometimes
necessary) ones, were potentially exploitable. As for your list
of ones to pass through unchanged, they do not appear even marginally
safe. USER & HOME: a setuid program (and any programs it calls)
should not need them; if they do, they shouldn't be trusted.
If a program needs these, they should be regenerated from reliable
sources. HOSTALIASES (and any other variable which affects DNS
lookup
Here is the beginings of a catalog of common environment variables
and a little about their potential exploitability. I started
with a printenv on an almost strait out of the box RedHat 3.0.3
system and added a few from memory.
RESOLV_HOST_CONF - Can be (ab)used to read any file on the system (resolver
libraries echo file if there is an error in it), crash
system by reading /dev/kmem, or to spoof name lookups.
ENV - Well known exploits
USERNAME - Any setuid program that needs this info had better
get it from someplace trustworthy
HISTSIZE - Don't know. Really large values or negative or zero
values might conceivably do domething strange to child
processes invoked by a setuid program
HOSTNAME - Any setuid program that needs this info had better
get it from someplace trustworthy
LOGNAME - see username
HISTFILESIZE - Don't know. Really large values or negative or zero
values might conceivably do domething strange to child
processes invoked by a setuid program
MAIL=/var/spool/mail/whitis
TERM - Very Dangerous. In addition to the TERMCAP problem,
csh is vulnerable to TERM - it EVALUATES it just like
bash evaluates ENV. Other shells may also.
If TERM is allowed, it must be used in conjuction
with a list of acceptable values.
Exploits:
- telnet/telnetd environment variable 'feature'
- older telnetd's still passed a terminal type even
if they dont let you set other environment
variables. So even telnetd's which have
fixed the telnet environ bug may still
be vulnerable to attacks on csh based
captive accounts.
- setuid programs which use shell scripts,
call system, etc.
- On system Vish systems:
login: script-user TERM='`/bin/sh</dev/tty>&/dev/tty`'
password: ...
$
- login -p based exploits:
export TERM='evil'
login -p
login: blah
Password: ....
...
echo $TERM
blah blah
TERMCAP - Very Dangerous (termcap entries can specify the
execution of arbitrary programs).
HOSTTYPE=i386 - Sometimes used in generating PATH
PATH - Very Dangerous
HOME - Any setuid program that needs this info had better
get it from someplace trustworthy and be very careful
what it uses it for in the first place. HOME points
to files created by an untrusted user.
SHELL - No setuid programs or captive login scripts should
need this should they? Obviously dangerous if used.
PS1 - Some buffer overrun attacks possible. In general,
setuid programs and captive login programs should
not be starting interactive shells but this could
have unexpected consequences internally to the shell
as well as to .profile files.
USER - See USERNAME
DISPLAY - Allows you to connect to any TCP port over 6000 (and
sometimes under 6000 using negative numbers) although
you may not have a lot of control over the data stream.
A possible way to attack things inside a firewall
when combined with things like the telnetd bug.
OSTYPE=Linux - See HOSTTYPE
SHLVL=1 - Unknown.
TZ - Affects time formatting functions. Potential for
several types of attacks:
- Forging time (i.e. you can cause a transaction
to appear to have occurred at a different time)
- Buffer overrun attacks in any programs which
print time.
- punctuation based attacks
LANG,
LC_ALL,
LC_COLLATE,
LC_CTYPE,
LC_MONETARY,
LC_MESSAGES,
LC_NUMERIC,
LC_TIME - These can cause standard library functions, such
as printf(), to do unexpected things, particularly
with regard to punctuation which can cause data
field misallignment based attacks in some situations.
IFS - Known exploits
LD_LIBRARY_PATH* - Known exploits (replacing shared libraries with
trojan versions, often via Anonymous FTP or similar
means), usually fixed for setuid programs
in ld.so.
LOCALDOMAIN,
HOSTALIASES* - Anything which can be used to spoof DNS is
potentially exploitable. critical programs
should use RED_NOALIASES on systems like linux
where this variable is implemented, although
that may not protect against LOCALDOMAIN.
Many of the above variables can be made more dangerous through their
explicit use in captive login programs, .profile, .login, .bashrc,.cshrc,
etc.
I have not even touched on some others:
PRINTER
LPDEST
EXINIT
WINDOWID
LESSCHARSET
EDITOR
VISUAL
NLSPATH
MSGVERB
NETPATH
SEV_LEVEL
any environment variables listed in man pages relating to
- any shell
- environ(5)
- ld.so
- libc
- any specific setuid program
should be added to the list
bash$ TERM='`/bin/ls >/dev/tty`' csh
[REW: In short, LOTS of environment variables are potentially
expoloitable. Only known "safe" variables should be passed (by
e.g. telnetd, or a setuid-wrapper). (I never knew about
RESOLV_HOST_CONF before it came up here.) And even "safe" variables
should be paranoidly checked against odd characters etc.]
---------------------------------------------------------------------------
--- Mark Whitis <whitis@dbd.com> WWW: http://www.dbd.com/~whitis/ ---
--- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 ---
---------------------------------------------------------------------------
