12

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'
herp

This is still allowed by design:

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

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
derp

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 '14 at 21:49
  • This question answers your second question well. – essefbx Sep 25 '14 at 22:33
12

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

  • LD_PRELOAD
  • LD_LIBARAY
  • BASH_ENV
  • 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 '14 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 '14 at 10:29
  • the ability to hide full paths is afaik considered a bug and removed with some patches. – Johannes Kuhn Sep 29 '14 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 '14 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 '14 at 10:32

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.