So, hum, bash…

So, I guess you heard about the latest bash hole.

What baffles me is that the following still is allowed:

env echo='() { xterm;}' bash -c "echo this is a test"

Interesting replacements for "echo", "xterm" and "echo this is a test" are left as an exercise to the reader.

Update: Another thing that bugs me: Why is this feature even enabled in posix mode? (the mode you get from bash --posix, or, more importantly, when running bash as sh) After all, export -f is a bashism.

2014-09-25 09:43:14+0900

p.d.o, p.m.o

Responses are currently closed, but you can trackback from your own site.

8 Responses to “So, hum, bash…”

  1. Cameron McCormack Says:

    Just read a good description of what’s actually happening there: http://lcamtuf.blogspot.com/2014/09/quick-notes-about-bash-bug-its-impact.html

  2. markus23 Says:

    zsh prevents this, so I would suspect the security problem still is not fixed.

  3. mirabilos Says:

    This is actually a feature of GNU bash. One I’ve never understood, because the () are in the variable body, and thus it can be abused like this. Or like $HTTP_USER_AGENT.

    But yes, this is by design. What was *not* by design was:
    $ env x='() { :; }; echo foo’ bash -c true
    foo

    Of course, you should be using mksh instead anyway ☺

    My Debian systems (and even *buntu, with small patches) run fine with mksh as /bin/sh (actually the /bin/lksh binary in current packaging), so I can get rid of dash fully, and use GNU bash only when explicitly called.

  4. Christoph Anton Mitterer Says:

    Well we have CVE-2014-7169 in the meantime…

    It’s riddiculous…

  5. voracity Says:

    While the (corrected) bash behaviour is pretty weird (OK, pretty bad), if there’s any finger pointing to be done, surely it’s at Apache and the design of CGI. When I first encountered (long, long ago) the fact that it put end-user alterable variables into a global environment where collisions were possible, I was gobsmacked — but everyone seemed perfectly OK with it, so I assumed it was safe. It wasn’t, and it still isn’t.

    PHP had its own equivalent with register_globals on by default, but the developers thankfully changed their minds and fixed that issue. Maybe it’s time to fix CGI too? Yes, it’ll be hard, but we should at least plan for it. Otherwise, I recommend that we all recommend disabling CGI.

  6. mirabilos Says:

    “After all, export -f is a bashism.” ⇒ but it’s the import that is harmful, here.

    “the design of CGI” no, setting well-defined environment variables to arbitrary values is perfectly fine. It’s the problem of GNU bash for choosing to interpret some *payload* magically different.

  7. Simon Says:

    Why is this feature even enabled in posix mode?

    I assume that it wasn’t deemed necessary… that if disabling it wasn’t actually a requirement for POSIX compliance, there was no point in adding code to disable it.

  8. David Schmitt Says:

    That doesn’t seem to work on jessie:

    david@zion:~$ env echo='() { xterm;}’ bash -c “echo this is a test”
    this is a test
    david@zion:~$ bash –version
    GNU bash, version 4.3.25(1)-release (x86_64-pc-linux-gnu)
    […]