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
Responses are currently closed, but you can trackback from your own site.
2014-09-25 10:11:16+0900
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
2014-09-25 10:40:47+0900
zsh prevents this, so I would suspect the security problem still is not fixed.
2014-09-25 10:47:44+0900
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.
2014-09-25 17:53:34+0900
Well we have CVE-2014-7169 in the meantime…
It’s riddiculous…
2014-09-26 07:14:15+0900
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.
2014-09-26 10:28:09+0900
“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.
2014-09-28 10:38:20+0900
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.
2014-09-30 09:30:33+0900
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)
[…]