At the risk of adding to the heap of "Shellshock"-related questions...

The Shellshock patch prevents arbitrary code from being executed after function definitions in environment variables. For example, here is what a patched version of Bash does when one tries to exploit the hole:

$ env foo='() { :;}; echo derp' bash -c 'echo herp'
bash: foo: ignoring function definition attempt
bash: error importing function definition for 'foo'

This is still allowed by design:

$ env foo='() { echo derp; }' bash -c foo

But if function definition through the environment is possible, then anyone with the ability to modify the environment can replace commands with arbitrary code (assuming the target script doesn't specify commands by absolute path):

$ env ls='() { echo derp; }' bash -c ls

While the Shellshock patch prevents things like the HTTP User-Agent header attack, where any environment variable can be used to execute code, it does nothing to prevent redefining existing commands.

A similar attack is already possible without function inheritance by modifying PATH to point to a directory containing arbitrary maliciously-named executables, but that scenario requires filesystem access. This one does not.

The question, then: does being able to redefine commands through the environment count as a vulnerability? Is there any common situation in which it could be exploited for nefarious purposes? (For example, Git/Mercurial over SSH, Gitolite...)

  • 1
    I think that this is potentially exploitable, but it maybe difficult to exploit in applications in the wild.
    – rook
    Sep 25, 2014 at 21:49
  • This question answers your second question well.
    – essefbx
    Sep 25, 2014 at 22:33

1 Answer 1


In theory, yes. But then you also have problems with

  • etc.

The biggest problem with shellshock is that the name of the environment variable does not matter, bash would execute code in it even if you never call e.g. HTTP_COOKIES (who would do that btw?)

The attacker usually can only choose a part of the variable name, and it is unlikely (but not impossible) that a function/program with such a name is called.

E.g. If you restrict your git over SSH so they can only invoke git, then the attacker needs to define a environment variable git - and this shouldn't be possible.

Update: There is an other possible local privilege escalation:

You can hide commands even if they are called with the full path

env /bin/date='() { echo fail; }' bash -c /bin/date

Which can mess with system (and other) calls - and this is a problem for SUID executable which use one of that functions as root.

  • I see; so unlike Shellshock, it's not really an issue in practice. Thanks.
    – Sam Harada
    Sep 26, 2014 at 0:42
  • 1
    +1 for the update, which completely inverts the sense of the answer from "not really" to "yes, completely".
    – Ben
    Sep 29, 2014 at 10:29
  • the ability to hide full paths is afaik considered a bug and removed with some patches. Sep 29, 2014 at 14:37
  • @JohannesKuhn, who puts the full path to ls in a script? Anyway builtins like cd and echo can also be overridden and they don't get the invalid token error. The whole feature needs to be burninated - like the SSL heartbeat it doesn't serve any real purpose and the only real-world use for it seems to be to compromise systems.
    – Ben
    Sep 30, 2014 at 9:17
  • 1
    schroot's user-modifiable-keys is an attack vector. schroot setup scripts run as root, with a mostly clean environment. user-modifiable-keys allows custom environment variables to be passed to those setup scripts, that can be set at the command line by the user.
    – ninjalj
    Oct 1, 2014 at 10:32

You must log in to answer this question.

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