Environment Variables 1

Attacks Through Environment Variables

Copyright © 2017 by Wenliang Du, All rights reserved.
Personal uses are granted. Use of these problems in a class is granted only if the author’s
book is adopted as a textbook of the class. All other uses must seek consent from the author.

S3.1. What is the difference between environment variables and shell variables?
Many people might get this wrong because shell and environment variables
sometimes are interchangeably used. But shell differ from environment
variable in that they are a copy of environment variable with the same
name, and is often given when a new process is initialized , so when we
change shell variable, the env stays the same . Basically shell is a copy of
env variable, but the changes occurred in shell variables does not affect env
variable
S3.2. In Bash, if we run "export foo=bar", does it change the environment variable of
the current process?
Yes
S3.3. The followings are two different ways to print out environment variables. Please describe
their differences:
$ /usr/bin/env
$ /usr/bin/strings /proc/$$/environ
First way is to call env ,which is not a built in command of system which will trigger a
new process to execute that command, which will gives us shell variable of that process
Second way is to call directly to print the strings inside the directory /proc/$$/ ($$ means current directory) and because every
process have a virtual file called environ there for we do strings /proc/$$/environ which will print the current directoy
environment variables
S3.4. In our code, when we use execve() to execute an external program xyz , we pass
NULL in the third argument. How many environment variables will the process running
xyz has?
No env , since the third argument is an array containing the environment variables,
if we pass NULL then obviously no array = no env variable.
S3.5. Bob says that he never uses any environment variable in his code, so he does not need to
worry about any security problem caused by environment variables. Is he correct?
Half half. Because what define an environment variable is still vague, for example I
can modify his ls command if he doesn’t use /usr/bin/ls (he don’t provide full path) I
can still make it do something malicious, then I can modify the path environment to be
echo PATH=.:$PATH (I put a dot at the front, meaning it will look for my code ls in
the current directory first ,meaning it will run first) , so even though no environment
variable is used in bob code, I can still disguide normal command as environment
variable if he is not careful
S3.6. A program abc invokes an external program xyz using system(), which is affected
by the PATH environment variable. When we invoke abc from a shell prompt, how
does the shell variable PATH in the current shell end up affecting the behavior of the
system() function?
 Hard to say, but my guess is that which ever abc is found first in the PATH gets
executed, because everytime we use system() we call a new shell, and new shell copy the
env path (inherit) so if we did something funny after calling xyz for example: changing abc
to a different program in a different directory then putting it first in the PATH , then our abc
program might be called differently( a different program might be called I mean)
S3.7. Please explain why using secure getenv() is better than using getenv().
It has buffer-overflow prevention and secure condition ,it does better env variable sanitization:
“Then environment variables are used by privileged Set-UID programs, they must be
sanitized properly. Developers may also choose to use a more secure version of getenv (), such as
secure_getenv () provided by glibc [die.net, 2017). When getenv () is used to retrieve an environment variable,
it will search the environment variable li st and return a pointer to the string found. The secure_getenv ()
function works exactly like getenv (), except that it returns NULL when "secure execution" is required [die.net,
2017). One of the conditions for secure execution is when a process's effective user/group ID does not match
with the real user/group ID; that is, the process runs a Set-UID or Set- GID program, and is thus privi leged.”

S3.8. A privileged Set-UID program needs to find out which directory it is currently in.
There are two typical approaches. One is to use the PWD environment variable, which
contains the full path of the current directory. Another approach is to use the getcwd()
function (you can find its manual online). Please describe which approach you would
like to take and why.
Use getcwd() ,because it querry directly with operating system, while pwd use the current
directory PWD env variable, which is modifiable
S3.9. In Linux, many environment variables are ignored if the program by the dynamic linker if
the program to be executed is a Set-UID program. Two such examples are LD PRELOAD
and LD LIBRARY PATH. Please read the manual of ld-linux (https://linux.
die.net/man/8/ld-linux) and explain why the following environment variables
are also ignored:

• LD AUDIT
• LD DEBUG OUTPUT

Same reason why LD_PRELOAD and LD_LIBRARY_PATH are ignored: because they are modifiable , and
can be redirected for bad purpose

S3.10. There are two typical approaches for letting normal users do privileged tasks, one is to
write a root-owned Set-UID program, and let the user run; another approach is to use a
dedicated root daemon to do those privileged tasks for users. Please compare the attack
surfaces of these two approaches, and describe which one is more secure.

The latter, because the first one has user input which interact directly with the system through
SET-UID program, while the other use a service, furthermore the input is from a
priviledge process (the privilege process is called by system, not user, and take system
input ) so more secure. Even though running a background process instead of a
program to deal with user input, we can sacrifice some optimization for the sake of
security.