4

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)

Community
  • 1
nerflad
  • 41
  • 1
  • 4
  • 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? – Brent Kirkpatrick Apr 09 '16 at 02: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 Apr 09 '16 at 02: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. – Brent Kirkpatrick Apr 09 '16 at 02:31

1 Answers1

3

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.
Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 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. – Brent Kirkpatrick Apr 09 '16 at 13:44
  • @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](https://www.google.com/search?q=environment+variables+privilege+elevation). And who would have thought that putting the contents of a harmless HTTP header into an environment variable could be dangerous thing (shellshock). – Steffen Ullrich Apr 09 '16 at 13:50
  • Just because a rogue employee gains access to one machine does not mean they have access outside that machine. In my experience, privilege escalation is easy for hackers, it is the initial intrusion over the network or by social engineering that is the difficult part for them. – Brent Kirkpatrick Apr 09 '16 at 14:04
  • @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. – Steffen Ullrich Apr 09 '16 at 14:12
  • I am certainly not arguing with you. My original comment also mentioned layered security or security in depth. I most certainly agree with you. I was asking about relative risk and cost/benefit of investing software development resources in addressing various vulnerabilities. It is impossible to address every vulnerability, so one must choose where to allocate development resources. – Brent Kirkpatrick Apr 09 '16 at 14:15
  • 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. – Steffen Ullrich Apr 09 '16 at 14:22
  • Shellshock is an ENV variable exploit: https://en.wikipedia.org/wiki/Shellshock_%28software_bug%29 – Brent Kirkpatrick Apr 09 '16 at 14:38
  • @BrentKirkpatrick: Shellshock is an exploit against bash **using** an environment variable. With a properly sanitized environment variable which only contains *expected* content (i.e. white list vs. black list) the exploit could not be executed. And of course if bash would not be so stupid to execute code from within **untrusted** environment variables. – Steffen Ullrich Apr 09 '16 at 14:55
  • `Depending on the OS other users on the system might see the content of the environment variables` which? I think you're thinking of command line arguments – Neil McGuigan Apr 09 '16 at 19:40
  • @NeilMcGuigan: I like you refer to the final paragraph of http://security.stackexchange.com/questions/14000/environment-variable-accessibility-in-linux/14009#14009: "...On some older unices, ps was a setuid root program that parsed some kernel memory; some variants would happily display a process's environment to any and all.". So current Linux does not let users users see the environment but some older UNIX versions did. – Steffen Ullrich Apr 09 '16 at 19:51
  • so it's fine to use env vars except with like AIX 0.9... – Neil McGuigan Apr 09 '16 at 19:55
  • @NeilMcGuigan: I think passwords in env are almost never a good idea and most applications just have the file descriptor or similar in the environment which then can be used to read the password. Just take a typical shared web server where code of different users all runs as nobody or similar - and you do not want anybody to get sensitive data just from peeking into the environment of other scripts running as nobody. – Steffen Ullrich Apr 09 '16 at 20:03
  • @SteffenUllrich 1. if you're running a web server on a shared host you don't care about security. 2. Search github for checked in passwords because people foolishly kept them in files and not envvars, you will be astounded. 3. Heroku and AWS are pretty successful and envvars is their approach 4. People mess up file permissions all the time. You can't mess up envvar permissions – Neil McGuigan Apr 09 '16 at 20:25
  • @NeilMcGuigan: to 1: it might not be the most secure way but I disagree that you don't care about security at all. to 2. I was talking about transferring the password via file descriptors, which is different to a file. It's more like a named pipe. 3. Heroku suggests environment vars because they are safer than (checked in) files. Which means they see this as the lower risk (and I agree) which does not mean that it is risk free. 4. again: I was not talking about files. - BTW: Heroku suggests to set the environment vars in bashrc which means again in a file on the system (but not checked in) – Steffen Ullrich Apr 10 '16 at 04:07
  • @NeilMcGuigan: BTW, the OP asked for possible risks and not to compare the risk of using environment variables with other risks. And like I said, the exact risk depends on the use case but you should be at least aware what kind of risks might be there. If you want to discuss the risk of using environment vars vs. some other technology in a specific use case I suggest you start a new question. – Steffen Ullrich Apr 10 '16 at 04:35