2

There are 2 things I don't understand about the shellshock vulnerability:

  1. Why is the injection of environment variables allowed to unverified connections? What is that good for?

  2. What actual services provide the ability to inject variables?

Any ideas?

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
noamelf
  • 53
  • 2
  • 8
  • Welcome to Stack Overflow. Please read the [About] page soon. This pair of questions (or two-part question) is really a bit broad. Also, the answer to the second is easily found on the web. You should certainly read the question and answers to [Is the behaviour behind the Shell Shock vulnerability in Bash documented or at all intentional?](http://stackoverflow.com/questions/26022248/) – Jonathan Leffler Sep 28 '14 at 00:00
  • Take a look at: http://unix.stackexchange.com/a/157495/74329 – Cyrus Sep 28 '14 at 00:16
  • One observation (counter-question): how does the shell know whether a connection is verified or not? – Jonathan Leffler Sep 28 '14 at 00:16

2 Answers2

2

Environment variables are a pretty common way of communicating with a child process. You might just as well ask "why is it allowed to pass arguments to a child process?" Of course, with environment variables a little more precaution is necessary, because some environment variables (PATH, for example) affect the semantics of some system calls. So the usual convention is to restrict the environment variables which can be set from untrusted input to a set of known names.

For example, the CGI protocol -- which uses environment variables to communicate information about the HTTP request -- restricts itself to a set of environment variable names specified in what loosely might be described as the CGI standard, plus arbitrary environment variables whose names begin with the characters HTTP_.

While CGI has possibly the largest inventory of user-input environment variables, the technique is pretty common. One well-established example is the use of TERM to define the terminal type of a remote terminal, but there are lots more.

Environment variables, like command-line parameters, need to be treated with care, and sometimes barriers are needed. The /bin/env utility provides a mechanism to clean the environment given to an executable, for example; that's useful if the environment is not trustworthy and essential if the executable is running with elevated privileges.

Aside from specific cases (like PATH), no application should rely on an environment variable being clean. Doing something on the basis of an environment variable's value without first checking its validity is as much of a bug as any other unvalidated use of user-provided data. (q.v. SQL injection attack.) And that's what we have here: a bug, plain and simple. These things happen. We're not perfect. (The fact that this bug has been present for over two decades apparently without anyone noticing is, at least, interesting.)

rici
  • 234,347
  • 28
  • 237
  • 341
-1

1) The vulnerability is an implementation bug. Injection of instructions into environment variables from an untrusted source was not intentionally allowed - that's why it's a bug.

2) See http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html#.VCNyvfmSx8E for a good example of how the vulnerability can be exploited.

mti2935
  • 11,465
  • 3
  • 29
  • 33
  • 1
    The problem is not environment variables per se; it's that the value of an environment variable was `eval`ed assuming it only contained a function declaration, without verifying that assumption. – chepner Sep 28 '14 at 02:50