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...)

Sam Harada
  • 123
  • 6
  • 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](http://security.stackexchange.com/questions/68122/what-is-a-specific-example-of-how-the-shellshock-bash-bug-could-be-exploited) answers your second question well. – essefbx Sep 25 '14 at 22:33

1 Answers1

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.

Johannes Kuhn
  • 294
  • 3
  • 10
  • I see; so unlike Shellshock, it's not really an issue in practice. Thanks. – Sam Harada Sep 26 '14 at 00: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 09:17
  • Your local privilege escalation on SUID executables would only work if they have uid==euid, otherwise bash will drop privileges. – ninjalj Sep 30 '14 at 19:22
  • @ninjalj Interesting. I currently don't have the time or environment to create a test for this, so I wonder if `system` from an SUID binary can result in this bug. – Johannes Kuhn Oct 01 '14 at 08:22
  • Only if that binary has uid==euid and gid==egid. However, euid==0 binaries will typically preserve the original uid. – ninjalj Oct 01 '14 at 09:12
  • 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 01 '14 at 10:32
  • I didn't even know about `schroot`, so I probably wouldn't have found that. – Johannes Kuhn Oct 02 '14 at 18:37
  • Actually, scratch that. Pulling a command redefinition attack would be much harder than just overriding LD_PRELOAD. It still would need some social engineering: you would need to make the sysadmin copy a vulnerable configuration with `ld.preload` buried somewhere in `user-modifiable-keys`. For command redefinition, you would need to also convince the sysadmin to install a custom setup script, which is fishier. It's all so much easier with shellshock, any variable in `user-modifiable-keys` would be enough! – ninjalj Oct 02 '14 at 21:11