I am writing a small cross platform Python application (a package manager to be used internally by my corp), and I'm thinking of using something similar to this answer on Stack Overflow to check for administrator/root privileges. I noticed the author mentions vulnerabilities with environment variables.

It isn't surprising to me that environment variables are vulnerable to overflows, etc., and that they would probably represent significant attack surface. Could I have some specific examples of attacks against them, especially what my application may be exposed to if it relies on them? Both WinNT and Linux examples are welcome.

(Also -- for various reasons we cannot use existing package management solutions such as Nuget/APT. We maintain our own distribution of internal software and writing a small specialized solution is easier, especially targeting multiple platforms)

  • Can you clear up my confusion: are you concerned about the risks to your phyton application of using an existing environmental variable? Or are you concerned about the risk to the system of an application writing to or reading an environmental variable? Commented Apr 9, 2016 at 2:03
  • Mainly my concern is with the system. I am concerned about a user becoming aware of the program's dependence on environment variables, and exploiting that dependency by setting the variable with a malicious value prior to execution.
    – nerflad
    Commented Apr 9, 2016 at 2:28
  • Prior to execution of your python application? Then you would need to make sure that you handle the variable well in your code. On the other hand, since this is an env variable that you are worried about, the attacker would first need access to the system in order to use the variable in an attack. Commented Apr 9, 2016 at 2:31

1 Answer 1


There are the usual risks associated with explicitly or implicitly trusting something which comes from outside and thus can be controlled by the attacker. And there is a risk of assuming that environment variables provide a restricted visibility which they don't do always. Some examples:

  • Implicitly trusting environment variables like PATH, LD_LIBRARY_PATH, PERL5LIB or similar can lead to unwanted execution of code because these variables decide where to look for programs and libraries. Similar variables like IFS decide how to interpret information given to the program. And sometimes the problem can be just any variable with a malicious content, like with the Shellshock vulnerability. That's why programs which use elevated privileges (like sudo) should remove or sanitize all environment variables when run by a non-privileged user. And programs which set environment variables (like webserver with CGI interface) should be very careful which possible attacker controlled information they put into these variables.
  • You should not use environment variables to pass sensitive information (like passwords) from a parent to the child processes. Depending on the OS other users on the system might see the content of the environment variables and thus grab these sensitive information.

Thus the rules when using environment variables are:

  • Never trust the content of these variables, neither explicit nor implicit. That means remove or sanitize the variables especially when the variables might be set by users with a different privilege then the program is running.
  • Never put sensitive information in environment variables because other users might read these.
  • If you set these variables with data which you did not fully generate yourself (i.e. possible attacker controlled) be very careful and sanitize everything to disarm it.
  • How large of a risk are the env variables, really? By the time the variables are compromised, the attacker would probably already have other access the python application. Most of us believe in layered security, so by all means, be careful with the variables. It just seems that the cost/benefit is low. It might be better to invest more time protecting the network access the application has. Commented Apr 9, 2016 at 13:44
  • 1
    @BrentKirkpatrick: Not everything can be done at the network level. The attacker might already be inside and just elevating its privileges. Think of a rouge employee or somebody trying to compromise a public internet kiosk etc. Defense in depth includes protection against elevation of privileges and environment variables can be really helpful to elevate privileges. And who would have thought that putting the contents of a harmless HTTP header into an environment variable could be dangerous thing (shellshock). Commented Apr 9, 2016 at 13:50
  • 1
    @BrentKirkpatrick: I don't think we need to argue what is the easy and what is the hard part. Obviously there are enough ways for an attacker to get non-privileged access and it might just that the attacker owns web space on the same system as the target. And since it is not possible to make non-privileged access completely impossible you have to make privilege escalation hard too. That's why you want security in depth vs. hard on the outside and soft on the inside. Commented Apr 9, 2016 at 14:12
  • 1
    @BrentKirkpatrick: I think a developer should be aware of the risks, same as (s)he should be aware of the other attack vectors. And then do risk-aware coding. Its hard to make a cost/benefit analysis here because it highly depends on the environment. It might be more of a problem on multi-user systems (UNIX, Windows Terminal Server) than on single user systems. But then Shellshock shows that it might not be that simple to find out up-front how large the risk really is. Commented Apr 9, 2016 at 14:22
  • 1
    Shellshock is an ENV variable exploit: en.wikipedia.org/wiki/Shellshock_%28software_bug%29 Commented Apr 9, 2016 at 14:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .