0

I asked a related question on defining and using shell functions in bash. In this question I want to ask specifically which way of defining function can lead to shellshock. I did some tests and I want to confirm with everyone else. I am running bash v4.2 for the test.

I understand to give a shell function definition to a subshell there are two ways:

  • via shell variables + export into environment
  • via shell function definition + export into environment

For the first way:

$ foo='() { echo "hello world"; }'
$ export foo
$ env | grep foo
foo = () { echo "hello world"; }

So for the second way:

$ foo() { echo "hello world"; }
$ export -f foo
$ env | sed -n '/foo/{N;p}'
foo = () { echo "hello world"
}

In both ways, the environment will have the shell function as a name-value pair [ foo = () { echo "hello world"; } ]. Now I am interested in CVE-2014-6271. I understand that this occurs due to how bash parses the trailing commands at end of function definition, but what I want to ask is whether both the above ways can lead to this ?

For first case, I can define:

$ foo='() { echo "hello"; }; echo "world";'
$ export foo
$ env | grep foo
foo = () { echo "hello"; }; echo "world";
$ bash -c foo
world // <-- shellshock bug
hello

However, for the second case, I'm not able to do the same:

// won't put trailing echo in definition
$ foo() { echo "hello"; }; echo "world"; 

// bad syntax
$ foo() '{ echo "hello"; }; echo "world";'

So my question is although CVE-2014-6271 happens due to a parsing bug in the trailing commands after function definition in environment variable, can such a function definition ever be put in the environment via export -f <func> OR is the first case the only way for putting a trailing commands to cause shellshock ?

  • 1
    It's possible, but not necessarily likely. The problem was never with export -f, but with the assumption that a environment variable starting with () { would always be a valid function definition to be evaluated. – chepner Oct 2 '15 at 20:13
  • I understand that. But given that wrong assumption and to exploit it, trailing commands can be put only via functions in shell variables ? Can I declare / export shell function explicitly and still use trailing commands to exploit shellshock ? – Jake Oct 2 '15 at 20:30
  • 1
    Maybe? If I could answer that affirmatively, I'd be submitting a patch, not demonstrating how to relive one of the loudest security scares of 2014. – chepner Oct 2 '15 at 20:33
  • export -f <func_name> require func_name is a valid function, its definition was interpreted by the shell. In case of putting function definition in environment variable, the interpreting was only done when importing environment. – cuonglm Oct 3 '15 at 4:23
  • @cuonglm The point was that in both cases I observe the function being put as a name value pair in the environment, so I was wondering if they are interpreted by a new child shell in the same way ? – Jake Oct 3 '15 at 20:51
0

Question:

... can such a function definition ever be put in the environment via export -f <func> OR, is the first case the only way for putting a trailing commands to cause shellshock ?

Answer: The first case is the only way to trigger shellshock.

The vuln is triggered by an interpretation of environment variables, not of exported functions.

Look at the Symantec image here. Read the description by the bug-reporter.

The processing of environment variables that happen to contain (){...} are processed as function definitions. And: of such variables that have a trailing ;cmd, the command cmd is executed. The core issue is that the parsing of functions does not limit the interpretation of one executable token, and process the rest of the line included inside an exported var as an executable command.

Limiting the execution to only one part of the exported variable was the first attempted patch. That was clearly insufficient as was quickly found on several additional bugs.

So, no, the bug is not the result of failing to export a function definition correctly, and; to be read back (which happens to be in complete control of the shell). But is the result of several problems in the parsing of variable values that may be injected by an attacker.

In any case the initial reporter of the bug is a regular user of this site. It is quite probable that he comes around to take a look at this question.

  • Why the down-vote???? What is wrong with this answer? So I can correct it or at least LEARN . Hidden down-voting helps no-one. – user79743 Oct 4 '15 at 0:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.