On Fri, 26 Sep 2014, Andrew McGlashan <andrew.mcglashan(a)affinityvision.com.au>
wrote:
On 26/09/2014 5:22 AM, Douglas Ray wrote:
those of you who haven't been up into the
small hours looking at the
... if you were looking at this then, then you were already probably far
too late on this.
wget -U "() { test;};/usr/bin/touch /tmp/VULNERABLE" \
http://www.example.com/cgi-bin/whatever
Above is a test for a vulnerable cgi-bin script courtesy of
https://twitter.com/hernano .
ssh root@localhost "() { :;} ; touch /tmp/ohno"
Above is a test I wrote for ssh where ~root/.ssh/authorized_keys allows access
but with the "command=" option (which sets the original command to the
SSH_ORIGINAL_COMMAND variable). Note that this doesn't do anything useful in
the case where unrestricted ssh access is granted.
This looks like something that must be fixed ASAP. In
relation to
Debian, it's been patched for Wheezy or Squeeze-LTS -- big problem if
you are still on Squeeze.
I've just tested the new version of bash for Wheezy, it fixes the bug.
This looks like a very serious issue that very quickly
become exploited.
I would hate to think about all those boxes running busybox and how they
might or might not be effected, but definitely a case of making sure
that such equipment is NOT Internet accessible by any process ... lock
down access to internal IP addresses, better still limit specific IP
address(es).
It seems that interpreted languages aren't a good choice when taking
unsanitised input from untrusted sources. The cgi-bin issue should have been
dealt with by the web server sanitising input (as well as Bash not working in
that way).
The ssh issue is due to sshd not being a good replacement for sudo.
--
My Main Blog
http://etbe.coker.com.au/
My Documents Blog
http://doc.coker.com.au/